------------------------------------------------------------------------------------- TODO List: * ivyprobe is a bit touchy about being fed somethin on standard input try echo "coucou" | ivyprobe ... * document the new features of IvyClient, the extension to the API * document the IVY_PING feature ------------------------------------------------------------------------------------- Known bugs: * it seems not to work with jdk1.1.7A VM. ( Yannick Jestin, François Regis Colin) * bus domain shortcuts ( 10:3456 instead of 10.255.255.255:3456 ) doesnt work (Yannick Jestin) ------------------------------------------------------------------------------------- Fixed: 1.0.12 - 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