I second jms for this, could you also put 'protection by sending cloud
id/name' to each message.

This is one of the reasons why i would prefer to have a NodeChangeEvent object.

This is a danger point of the current
implementation. Also Andre's problems at the start of the thread are
not (imho) related to multicast itself but a until not defined/found
problem of why a burst and more important why is this
a problem on the clientside (since they should be really quick).

Yes i understand this, maybe it has to do with the application server.
But, there are better ways to handle asynchronous requests instead of starting a thread for every request you receive. You could think about a producer / consumer mechanism with a producer that puts the incomming requests in a queue.


Rob




Reply via email to