Ken--_at_newsgroupstats.hk wrote:
> rmi is not non-blocking in standard jdk, right? any plan for implement a
> non-blocking rmi by grizzly?
>
Since RMI is really a programming model (with two completely different
implementations:
RMI-IIOP and RMI-JRMP, each with a different protocol), it sits above
Grizzly, since Grizzly
really only provides transport services.
I doubt there are any plans to put RMI-JRMP on Grizzly. That would be
coming from the
Sun east coast RMI (JRMP) group in any case, and I don't know of any
communications
from them about Grizzly.
RMI-IIOP is another matter: the CORBA team is currently working on
moving all of the ORB
transport code to Grizzly. This also implies that Grizzly will need to
be in the JDK once
we put the ORB-on-Grizzly work into the JDK, but there are currently NO
plans
to expose Grizzly APIs for use outside of the JDK (and no JSRs or other
standards work
currently planned in that area).
An asynchronous RMI implementation is yet another issue, one that is
completely unrelated to the
RMI on Grizzly questions (since either flavor of RMI could be extended
to support
async behavior regardless of the underlying transport). I don't know if
there is
any consideration of this in the RMI-JRMP camp: they are not active on
the Grizzly mailing
lists.
For RMI-IIOP, there once was a plan to do something like what you are
asking (I talked to
an engineer from Borland about this many years ago), but that plan never
really went
anywhere. It might be possible to do something like this mostly
transparently, essentially
by returning a future implemented as a proxy to the return type for a
method invocation.
Other tricks would be needed in cases where the return type is not
suitable for this approach.
It could also be done more directly by mapping the remote interface into
an asynchronous
future-based interface with a bit of runtime support for async calls.
This second case would
be a significant extension to the RMI programming model. This second
case is essentially
what was done for the AMI async extensions to CORBA.
Do you have strong requirements for such a feature? I'd be interested
in knowing more
about any such requirements.
Thanks,
Ken Cavanaugh
(I'm the ORB tech lead, and also one of the engineers working on Grizzly).