Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Remoting Update
Date: Mon, 24 Nov 2003 19:32:55 +0100
Message-ID: <5C3713B4B134BA49AFEAF154D0A1EE1C3F2E12@mlnexc01.emea.cpqcorp.net>
Thread-Topic: Remoting Update
Thread-Index: AcOyrkrU/sWpYSs/ReOFelf66INNKQAAT0JA
From: "Bordet, Simone" <simone.bordet@hp.com>
To: <geronimo-dev@incubator.apache.org>

Hi Aaron,

>> Having written such a remoting framework once, and then having=20
>> implemented JSR 160, I think that the JSR 160 approach is simpler and =

>> still almost equally powerful. For example, I would not make anymore=20
>> my listeners to be Remote in the RMI sense so that when a =
notification=20
>> is to be sent to that listener, the server calls the client via RMI.=20
>> 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=20
> 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=20
> machine, and the conenction is lost, how is the server supposed to =
handle it? =20
> I would like the listener to be removed, instead of the server=20
> getting an exception on every Notification thereafter.  What's the=20
> 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=20
>> EUR.

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

Urgh ! :-$

> Alright, well, maybe not quite.  :)

:D

Cheers

Simon