geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bordet, Simone" <simone.bor...@hp.com>
Subject RE: Remoting Update
Date Mon, 24 Nov 2003 18:32:55 GMT
Hi Aaron,

>> Having written such a remoting framework once, and then having 
>> implemented JSR 160, I think that the JSR 160 approach is simpler and 
>> still almost equally powerful. For example, I would not make anymore 
>> my listeners to be Remote in the RMI sense so that when a notification 
>> is to be sent to that listener, the server calls the client via RMI. 
>> That was the old MX4J remoting style of sending remote notifications. 
>> I have to say that I like JSR 160's more.

>	Now you're getting out of my depth.  I'd love to see you talk to Hiram 
> about the differences between your JSR-160 implementation and the remoting 
> framework that's currently in place.

Love that too, since I know very little of it: it is meant as a replacement of RMI/JRMP ?
I think JSR 160 and a remoting framework have both reason to exist, as they serve different
purposes.
Last time I spoke with the core developers (was with Dain ?) I've understood that JMX would
have not be used to make J2EE calls (to EJBs to be clear), the reason being JMX is too slow.
In this view, a remoting framework that takes care of EJB calls is orthogonal to JSR 160.
OTOH, JSR 160 is quite pluggable, and should be possible to plug in the remoting framework
to create a JSR 160 connector.
MX4J offers a lot of base classes to do so, and it does already for 2 non-specified protocols:
the local one and a remote over SOAP (with Axis).

>	But let me ask you this.  If the listener does happen to be on a remote 
> machine, and the conenction is lost, how is the server supposed to handle it?  
> I would like the listener to be removed, instead of the server 
> getting an exception on every Notification thereafter.  What's the 
> mechanic for ejecting the broken listener?

IMHO handling listener removal in a correct way requires a leasing mechanism a la Jini (one
can then ask why not using Jini; and there were several supporters of this solution, that
was finally discarded by the JSR 160 expert group - if you're interested I can tell you why).
Removing the listener altogether at the first failure may not be suitable in every case.

JSR 160 took a different approach (for several reasons): listeners are always local, and notifications
are polled and not pushed (before saying boooo, let me go on explaining :)

When from a client you register a listener on a remote MBean, the client listener remains
client-local and non-remote; the server is instructed to add a server-local (and non-remote)
listener to that MBean. When the MBean emits a notification, the server-local listener adds
it to a notification buffer (that has a limited capacity).
The client then polls the notification buffer asking notifications for its listeners. If the
connection is down, this polling cannot take place, and basically the listener on the client
is never notified. On server notification will queue up, until they are purged from the notification
buffer (reaching of capacity).
If the client is then able to connect again, the server will send it the queued notifications.
The polling mechanism in JSR 160 can be seen as a push mechanism initiated by the client,
and it is fair both in term of responsiveness and network traffic (2 problems of a classic
polling approach).

It may also happen that a JSR 160 connector client gets DGC'ed.
In that case, the behavior would be to remove all listeners registered by that connector client.
MX4J for now does not do this, and I reserve to myself more time to think if it will be the
right thing to do (which I'm not sure of).
At the end, you get a dangling listener on the MBean on server-side that fills up the notification
buffer that eventually purges its notifications (if the DGC-driven mechanism is not in place)
since the corresponding - disconnected - client never ask for notifications.

Note also that only in RMI/JRMP you have DGC (not in RMI/IIOP, for example).

Given that, a remoting framework used to make JMX calls should IMNSHO be based on JSR 160,
as a pluggable protocol.
As such, should exploit the features of the protocol to handle the case you mention. If Geronimo's
remoting framework has leasing would be great; if not, but has DGC (because it's based on
RMI/JRMP), great; if not (because it's based on a custom protocol) I am inclined to think
that the default JSR 160 approach is the less surprising - but here I'm somehow biased ;)

Don't know if I have confused you more (maybe I missed the point), but feel free to ask more.

>> Sorry if I am way out of path here, just wanted to throw in my 0.02 
>> EUR.

>     I think you have in inflated sense of your own importance -- 0.02 
> Euros is like 3 cents and that's 50% more than any else's ideas are worth!  

Urgh ! :-$

> Alright, well, maybe not quite.  :)

:D

Cheers

Simon

Mime
View raw message