1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
-------------------------------------------------------------------------------------
TODO List:
* ivyprobe is a bit touchy about being fed somethin on standard input
try echo "coucou" | ivyprobe ... -> use IvyDaemon instead
* document the extension to the API
* document the IVY_PING feature
* use the same commands and switches for Probe as in the C ivyprobe
* write a domain checker
* implement the direct Messages in Probe
-------------------------------------------------------------------------------------
Known bugs:
réf: [BUGXX]
Using the Blackdown Linux jdk 1.1.8_v3, the console is flooded with the
following messages :
-->ivy<-- Error IvyServer exception: Socket closed
Ivy server socket reader caught an exception Socket closed
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.close(PlainSocketImpl.java:408)
at java.net.SocketImpl.reset(SocketImpl.java:227)
at java.net.ServerSocket.implAccept(ServerSocket.java:207)
at java.net.ServerSocket.accept(ServerSocket.java:181)
at fr.dgac.ivy.Ivy.run(Ivy.java:441)
at java.lang.Thread.run(Thread.java)
It seems to be a bug in the JVM implementation. This is reproduced with the
-native and -green flags .
It doesn't happen with the 1.1.7A sun JDK on a solaris box.
réf: [BUGXY]
Using the blackdown jdk 1.2.2
Classic VM (build Linux_JDK_1.2.2_FCS, native threads, sunwjit)
The program sometimes hang or head to a SIGSEGV ( extract below )
SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Succès
si_code [1]: SEGV_MAPERR [addr: 0x890096C]
stackpointer=0xbe9ff234
Full thread dump Classic VM (Linux_JDK_1.2.2_FCS, native threads):
"Thread-6" (TID:0x40efc090, sys_thread_t:0x8219e78, state:CW, native
ID:0x4000) prio=5
"Thread-3" (TID:0x40efc030, sys_thread_t:0x821ab88, state:R, native
ID:0x20009) prio=5
at fr.dgac.ivy.IvyClient.<init>(IvyClient.java, Compiled Code)
at fr.dgac.ivy.Ivy.addClient(Ivy.java, Compiled Code)
I don't know if it is the jvm thread implementation or my code. I will
eventually investigate.
-------------------------------------------------------------------------------------
Fixed:
1.2.2
- java fr.dgac.ivy.Probe
- ivyprobe, quitte ivyprobe
il restait une thread IvyClient qui boucle en lecture. Bug reported by Damien
Figarol
- JDK1.1.7A (Sun) Method add(java.lang.Object) not found in class
java.util.Vector. -> replaced by addElement , the add(Object) was included
in jdk1.2. The System.setProperty was included in jdk1.2. I switched back
to the old constructs
1.2.1
- bus.start(null)
- java -DIVY_PING -DIVY_PING -classpath ../lib/ivy-java.jar:. BenchLocal -t 2 -d 100
créé une nullpointerexception java.lang.NullPointerException
at fr.dgac.ivy.Ivy.stop(Ivy.java:157)
at BenchLocal$RML.receive(BenchLocal.java:87)
at fr.dgac.ivy.Ivy.callCallback(Ivy.java:348)
at fr.dgac.ivy.IvyClient.newParseMsg(IvyClient.java:361)
at fr.dgac.ivy.IvyClient.run(IvyClient.java:191)
at java.lang.Thread.run(Thread.java:484)
fixed a condition when a bus was requested to be stopped even before
having started its thread
1.2.0
- implement .die in Probe ( to get the same behavior as ivy-c ivyprobe ) .
Done
- Probe doesn't send empty strings -> it does now
- the Unitary test fr.dgac.ivy.Ivy main() fails with jdk1.3, but succeeds with 1.4
it means that when a remote client disconnects brutally, the IvyClient and IvyWatcher
Threads are still hanging, ready for a new connexion !
In jdk1.3.0, it works whithin jdb but not as a single application
-> fixed with a new setSoTimeout(TIMEOUTLENGTH) on each socket.
- jdk1.4 DEBUG TCP socket reader caught an exception Socket closed on Ivy.close()
- if a remote client disconnect brutally ( broken pipe ), the BufferedReader
takes time to propagate the IOException. It means we are not aware of the
problem before 2 or 3 messages ( Alexandre Lemort )
there is a fix in IvyClient, but this is part of the TCP protocol. I will
receive the timeout when I try to write on the client. To circumvent this, I
have implemented an extention in the Ivy protocol with 2 new messages, Ping
and Pong. This is Ivy-java only, and and experimental feature.
- when a Ivy bus sends a die message, he dies instead of making the other leave
* 1.0.11: received an exception: IvyClient.sendBuffer.write failed: Relais brisé (pipe)
It happens while sending messages once a remote client has disconnected
( fixed in 1.0.12 )
-------------------------------------------------------------------------------------
Not a bug ?
if you send a msg just after the start, it is possible that the message
won't be sent. this is *not* a bug, but, hmmm, a feature. In fact, when you
do start(), it triggers different threads, the broadcasts are sent, and it
is possible that nobody has answered this broadcast by the time you start
sending messages. Try adding an IvyApplicationListener with a callback on
connect(IvyClient) to trigger the launching of messages
lun jan 6 16:12:11 CET 2003 (Yannick)
If you bind to a Start message after invoking the Ivy.start() method, it is
possible that you will miss the start. Be sure to check that all static bindMsg()
are done before the start, in order not to miss a message.
This is *especially* true when writing benchMarks
bus domain shortcuts ( 10:3456 instead of 10.255.255.255:3456 ) doesnt work
for UDP broadcast on my development environment. It's okay in multicast (Yannick Jestin)
In fact, it's a matter of network topography, not of shortcut processing.
Using the regression tests on the following platforms:
- Solaris: I've got a problem to make it run on the default local Domain
(127:2010). But this is not limited to the java ivy port !
success with jdk1.1.7A, on jdk1.2 , j2sdk1.3 and 1.4 with a multicast domain or a valid
UDP broadcast domain . I guess it's a routing problem once again :-\
- GNU/linux: ok with jdk1.3 and jdk1.4
- windows: I don't know how to write tests
lun jan 6 16:13:30 CET 2003 (Yannick)
disconnect() is not called when we send a "die" command to the remote IvyClient
It is normal. disconnect is called when we are issued a die command.
|
