Why not to use java NIO with object brokers supporting the Request-Process-Response pattern

Today i’ve released a new version of EJOE, my lightweight java implementation of the Request-Process-Response pattern. For a full description of EJOE visit the project site. One of the new features is that it uses now *old-style* blocking IO streams for sending/reading requests and responses by default. NIO is used only for selecting and accepting incoming connections as well as during EJOE’s handshake feature.

Now i can hear the NIO fans shout: “What? You cancelled using NIO?! Using Channels.newOutputStream() and/or Channels.newInputStream() is for newbs!”

What shall i say? Yes i cancelled the default usage of NIO. I use NIO features for ensuring high-latency during connection selection and acception only. The usage of ByteBuffers and non-blocking read/write IS unfortunately not the way to go for object based Request-Process-Response implementations. Such implementations – especially object broker servers like EJOE – have to deal with object (de)serialization because they don’t know anything about the data they serve, they don’t use a special protocol. A client send some objects – the request – which will be processed by a serverside working horse. That serverside part will response in objects as well. See the problem? All these objects have to be (de)serialized and with NIO it works more or less like this:

1. the client get’s an object – the request
2. the request-object gets serialized completely into a ByteBuffer
3. the ByteBuffer is send to server
4. the server reads the request completely into an ByteBuffer
5. the request-object gets deserialized from the ByteBuffer
6. the request-object gets handed-over to a (black boxed) process component
7. the process component returns an response-object
8. the response object gets serialized into a ByteBuffer
9. the ByteBuffer gets send to client
10. the client reads the response completely into a ByteBuffer as well
11. the response-object gets deserialized from the ByteBuffer

The key here is the (de)serializing part. The solution above can’t do direct (de)serialization from a socket connection because it *has* to use ByteBuffers. Using at least partial blocking IO with Channels.newInputStream()/Channels.newOuputStream() is the way to go to even though some guys think these methods were borne in a hell full of idiots.

Look at the process when we use these blocking streams:

1. the client get’s an object – the request
2. the request-object is serialized and send in one combined operation, eg. new ObjectOutputStream(Channels.newOuputStream(mychannel));
3. the server deserializes the request-object directly as well in one combined operation, eg. new ObjectInputStream(Channels.newInputStream(mychannel));
4. the request-object gets handed-over to a (black boxed) process component
5. the process component returns an response-object
6. the server serializes and sends the response-object in one combined operation
7. the client reads and deserializes the response-object in one combined operation as well

End of the story don’t use channel.write(bytebuffer) and channel.read(bytebuffer) when you know that your process component can’t handle the raw bytes contained in the bytebuffers. If you need (de)serialization NIO is definitely NOT the way to go.

so long

netseeker

Update 03/13/2005: As of version EJOE version 0.3.3-dev the difference between blocking and non-blocking IO isn’t that clear anymore. With full support of partial reading/writing of ByteBuffers, using non-blocking IO can be faster than blocking IO, especially when using little data objects. The memory consumption is higher anyway and the larger data objects are, the faster non-blocking IO is.

comments as well as critism is appreciated and alway welcome. just send your comment to mailto:netseekerATmanskesDOTde.

Leave a Reply

Using Gravatars in the comments - get your own and be recognized!

XHTML: These are some of the tags you can use: <a href=""> <b> <blockquote> <code> <em> <i> <strike> <strong>