geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Remoting Update
Date Mon, 24 Nov 2003 22:38:12 GMT

>>>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
Yep kinda.  the current stuff is meant to be close the wire RMI style 
replacement.  So after having read your post, I think i agree that JSR 
160 is in a different space than geronimo remoting.

>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
>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).
I would be interested in finding out more about how to use our remoting 
to create a jsr 160 connector.

>>	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).
I like the queuing idea (coming from a jms background)... but it would 
still be nice to push to the client if the protocol supports it.

>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.
Good points...  how would a protocol layer inform the jsr 160 layer that 
a listener needs to get gced??

>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
Sounds good to me..   How can I get started creating 160 clients and 
furthermore, how can I plug our remoting protocol into 160?

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

You've brought great insight...  keep it coming :)


View raw message