aboutsummaryrefslogtreecommitdiff
path: root/BUGS
blob: ad63254ed6e1c5f716252bad0617f5e3a0d671e4 (plain)
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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
-------------------------------------------------------------------------------------
Won't do list:
  * implement an interface allowing different regexps implementations, since
    it exists in jdk 1.4.1 !, while keeping in mind the platform compatibility
    -> nooooo ( jakarta regexps now )
-------------------------------------------------------------------------------------

TODO List:
  * try the "many threads option" for sending messages
  * make a ssh tunnel

-------------------------------------------------------------------------------------
Known bugs:

réf: [BUGYANN]

  perte des arguments ...
  jdk 1.4.2_04 sous OSX peut amener à
  [1:40:51 PM] 3/5 packets received (3)
  [1:40:51 PM] sender has sent all its packets, waiting for a die message
  -->IvyClient[0] MSreceive (remote MSsend)<--  string array 0 elements:
  -->IvyClient[0] MSreceive (remote MSsend)<--  string array 2 elements: (5) (aaaaaaaaaa)
  et du coup un ArrayOutOfBoundsException  dans le receive

  c'est le cas en async sur le test Async uniquement, depuis les jakarta
  regexp...

réf: [BUGMATT]

  concurrent connexion leading to noone or double connexion ...
  pour reproduire: Kaffe sur un pécé quadriproc

réf: [BUGXZ]

  on debian woody, using Kaffe, one cannot build the jar file ( problem in
  manifest ? ) beware, when building java for woody, to use the regexp.jar and getopt.jar
  built for your version of java ( Major/Minor version mismatch ... )

  on the following kaffe version, tests sometimes fail
  Kaffe Virtual Machine
  Copyright (c) 1996-1999
  Transvirtual Technologies, Inc.  All rights reserved
  Engine: Just-in-time v3   Version: 1.0.5   Java Version: 1.1

  make test2:
  kaffe -DIVYBUS=224.5.6.7:8910 -classpath .:../lib/ivy-java.jar:/usr/share/kaffe/Klasses.jar BenchLocal -t 2 -d 0
  [...]
  * [9:21:53 AM] BUS2 left
  * [9:21:53 AM] BUS1 left
  * [9:21:53 AM] BUS2 left
  Dumping live threads:
  `Thread-8' tid 0x837b010, status SUSPENDED flags
   blocked@0x8353510 (0x837b010->|)
   `gc' tid 0x81e0010, status SUSPENDED flags
    blocked@0x81abdc0 (0x81e0010->|)
    `finaliser' tid 0x81d7010, status SUSPENDED flags
     blocked@0x81abd90 (0x81d7010->|)
     Deadlock: all threads blocked on internal events
     make: *** [test2] Abandon

  make async, stack overflow in jakarta regexp

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.7

  réf: none, unbind déconnait (Mathieu Raynal)
  réf: none, bug perl implementation (Jean Paul)

1.2.4

  réf: [BUG J007] incorrect handling of faulty remote Ivy agents
    for exemple, bad UDP broadcasts, or wrong regexps.

  réf: [BUG J006]
  *  incorrect notification of agent departure
    $ java -DIVY_DEBUG fr.dgac.ivy.Probe
    $ ivyprobe
    and ^C the ivyprobe results in :
    IVYPROBE connected
    -->IvyClient JPROBE:IVYPROBE<-- readline null ! leaving the thead
    -->IvyClient JPROBE:IVYPROBE<-- normally Disconnected from IVYPROBE
    -->IvyClient JPROBE:IVYPROBE<-- Thread stopped
   The 1.2.4 releases produces a IVYPROBE disconnected

  réf: [BUG J005]
  * better handling of non Ivy broadcast messages
    $ jprobe
    $ echo coucou | nc -q 0 -u -b 127.255.255.255 2010
    throws a numberformatexception and stays in a unstable mode for the
    relevant domain.

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)
  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.