Patrick,
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<[email protected]> 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):
http://issues.apache.org/jira/browse/RIVER-101
http://issues.apache.org/jira/browse/RIVER-102
http://issues.apache.org/jira/browse/RIVER-157
http://issues.apache.org/jira/browse/RIVER-158
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:
http://issues.apache.org/jira/browse/RIVER-99
http://issues.apache.org/jira/browse/RIVER-103
http://issues.apache.org/jira/browse/RIVER-137
http://issues.apache.org/jira/browse/RIVER-141
http://issues.apache.org/jira/browse/RIVER-177
http://issues.apache.org/jira/browse/RIVER-280
-- Peter
