river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Jones <...@roundroom.net>
Subject Re: [Was: OSGi and Jini] Now -> Next Steps
Date Sun, 16 Aug 2009 05:39:59 GMT

Sorry for taking so long to answer your question:

On Jul 15, 2009, at 12:05 PM, Patrick Wright wrote:

> Hi Peter
> On Wed, Jul 15, 2009 at 5:59 PM, Peter Jones<pcj@roundroom.net> wrote:
>> Just to be clear, the "com.sun.jini.jeri.tcp.useNIO=true" mode of the
>> JERI TCP endpoint implementation still uses multiple threads to
>> dispatch remote invocations-- RMI behavior would be drastically
>> impacted if it only used a single thread for that (for reasons like
>> you describe below).  It just uses a single thread for performing I/O
>> operations, at least those that "would block".
> Do you happen to know if there is documentation from the time when the
> NIO support was added, for example, regarding benchmarks, problems,
> etc.?

There has been some discussion about these things over the years on  
mailing lists like JINI-USERS (archives still online as of now) and,  
IIRC, the jini.org mailing list for the Davis project (the code name  
for the jini.org project that developed the 2.0 Jini starter kit  
release)-- alas, the Davis mailing list archives haven't been online  
for many years, ever since jini.org stopped hosting projects, and I  
don't know that they were preserved anywhere.  (Maybe Jim Hurley would  
know for sure?)

I no longer have many performance/benchmark notes that I had at Sun.

Some issues with the JERI NIO implementation are documented as River  
bugs (filed as clones of Jini bugs in the Sun database):


The first two are much more significant than the last two.

The current JERI NIO implementation was largely written around the  
same time as Java's NIO itself was being developed, for J2SE 1.4 (this  
was back around when what is now JERI was part of JSR-78 intended for  
J2SE 1.4), and it has changed little since then.  Some of the  
implementation techniques were chosen in consultation with the NIO  
expert group.  But I think that the Java community has learned a great  
deal about how to make the best use of the NIO API in the many years  
since then, and I suspect that many lessons learned could be used to  
improve (or replace) existing JERI NIO code.

RIVER-101 is a case of a design choice that seems suboptimal now,  
especially as the NIO implementation has evolved.  RIVER-102 is a case  
where more thought should be put into what seems to be a critical  
performance aspect (especially for multiprocessor systems, IIRC).

Incidentally, here are some other performance-related JERI RFEs, not  
specifically related to the NIO implementation mode:


-- Peter

View raw message