Re: [Openjmx-devel] RMI adaptor and remote notifications

[B. <jer...@xt...>]

Bordet, Simone wrote:

>>If you want to garanty order then if you have one remote 
>>reference that 
>>is "dead" (because of network failure or client crash), you 
>>will block 
>>the server on this item and the other notifications won't be 
>>sent before 
>>a while. Is it really important to have a sequential order of 
>>notifications? What about adding (like Jini) an eventID and increment 
>>this ID each time a notification is sent. That way the client can 
>>"re-construct" the order if it matters.
>>
>
>JMX already has event IDs, fortunately.
>I was talking about filter + notify: these are 2 remote calls, and I should not do the second if the first filters it out. So I must wait for the first to complete.
>
>So, for each listener I can span a thread, but this thread must call filter AND notify. One thread per remote call is not good.
>
>I don't care notification ordering.
>
Ok. We were not speaking about the same thing then :-)

Perhaps a pool of thread each handling a "filter+notify" operation would 
be better? Creating threads is really time consuming in Java...


Jerome.