Re: Socket factories with JERI / JERI vs. JRMP performance penalties

Hi Mark, 

First i'd just like to report that i was finally sucessfull in creating JERI connections that obey read and write timeouts by using NIO based Socket factories, although that was somewhat tricky. The reason it didn't work 'out of the box' was, that JERI internally tests if the socket it has got from the SocketFactory has an underlying NIO SocketChannel by calling Socket.getChannel(). If this returns not null, JERI uses this SocketChannel directly, and does not call Socket.getInputStream() neither Socket.getOutputStream(). 

My Socket factory is coded following the guidance given in 
http://java.sun.com/javase/6/docs/technotes/guides/rmi/socketfactory/index.html, means it has it's timeout functionality wrapped into the streams returned by Socket.getInputStream() and Socket.getInputStream(). Initially, the coding of my Sockets internally delegated Socket.getChannel() to the underlying socket obtained via SocketChannel.socket(). As this returned the SocketChannel, JERI simply bypassed my functionality. The simple solution was, to return null from my own Socket.getChannel(), instead of delegating this method. This way i could trick JERI to use my streams.

I also tried another way, i.e., to return a subclass of SocketChannel from Socket.getChannell, that has it's own implementations of the various read() and write() methods provided by SocketChannel. However, this gets complicated, as Jeri internally uses Selectors with a SocketChannel. Unfortunately, inside NIO it is somewhere checked whether the SocketChannel worked on is derived from sun.nio.ch.SelChImpl, what means i would have to implement this interface in my subclass of SocketChannel. As this interface is sun-internal, i think it is not portable to use it in application code, and gave up with this idea.

Anyways, all this tricks with socket factories give me a little 'hacky' feeling. Having roundtrip timeout constraints supported directly by JERI would look much cleaner in my opinion.

Now comes the more interesting part:

When playing around with SocketFactories, i made somewhat alarming observations w.r.t. performance: Transferring a single large chunk of data with JERI took about 10 TIMES as long as transferring it with JRMP. With client and server on the same (otherwise unloaded) linux-2.6.17 machine, actual throuput with JERI is about 6 MByte per second, with JRMP it's about 60 Mbyte per second. First i thought, the reason was my SocketFactories, but the same factor shows up with the standard built-in socket factories ! I guess this is caused by JERI's multiplexing features, which may show another picture if multiple concurrent calls are made. However, a factor of 10 in this quite simple test seems extremely high, doesn't it ? I'd wonder if anybody else has reported this, or if its a mistake in my test program. 
BTW, under windows (on the same machine), performance is about 20% better, but the ratio between JRMP and JERI is the same.

Cheers, Martin


 
************************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
************************************************