[jira] Created: (RIVER-318) JERI Performance Issues

["Peter Firmstone (JIRA)" <ji...@apache.org>]

JERI Performance Issues
-----------------------

                 Key: RIVER-318
                 URL: https://issues.apache.org/jira/browse/RIVER-318
             Project: River
          Issue Type: Improvement
          Components: net_jini_jeri
            Reporter: Peter Firmstone
            Priority: Minor


Peter Jones made some very good comments on the river-dev mailling list I'd like to tie together for later reference.

Sounds like there are definitely some opportunities for improvement:

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<pc...@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):

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


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.