Hi..
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.
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 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).
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 more.
You've brought great insight... keep it coming :)
Regards,
Hiram
