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

[Bordet, S. <Sim...@co...>]

Hi,

> >>The=20
> >>problem with this scheme is that you should try to send some=20
> >>few times=20
> >>the notification (there might be a network congestion for=20
> >>example) if it=20
> >>does not work the first time. The call should be threaded too=20
> >>because we=20
> >>do not want to block the server while calling the client.=20
> >>
> >
> >No, I do want. At least must be sequential the call for=20
> filtering and notification...
> >Actual implementation is in same thread however: for server=20
> there is no difference between local and remote (I know, I know... :)
> >
> If you want to garanty order then if you have one remote=20
> reference that=20
> is "dead" (because of network failure or client crash), you=20
> will block=20
> the server on this item and the other notifications won't be=20
> sent before=20
> a while. Is it really important to have a sequential order of=20
> notifications? What about adding (like Jini) an eventID and increment=20
> this ID each time a notification is sent. That way the client can=20
> "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.

Simon