Interesting news putting, Grizzly into the JDK..
I just hope that putting Grizzly i the JDK doesn't cause the kinds of
problems we've seen with old versions of supporting libraries "frozen" in
the JDK and causing problems for applications, such as Glassfish, wanting to
use newer versions.
/Jesper
2008/6/5 Ken Cavanaugh <Ken.Cavanaugh_at_sun.com>:
> 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).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>