Where to read NIO data to?

Thread view:

meselfo - 30 Nov 2007 21:34 GMT

Im trying to write a small nio server. Its ServerChannel is configured
for nonblocking operation. When a SocketChannel becomes readable I
read the data into a ByteBuffer - but the data may not be complete so
I cant start processing it right away - so where do I store the data
untill I have a complete message? I use the same byte buffer whenever
data becomes readable on a socketchannel. The data is XML fragments
and I only want to start parsing it once I have the end tag of the
fragment.

Reply to this Message

Crouchez - 30 Nov 2007 23:49 GMT

> Im trying to write a small nio server. Its ServerChannel is configured
> for nonblocking operation. When a SocketChannel becomes readable I
[quoted text clipped - 4 lines]
> and I only want to start parsing it once I have the end tag of the
> fragment.

you could stick it in a bytearrayoutputstream or do this: buf >
pipedoutputstream > pipedinputstream

Reply to this Message

Esmond Pitt - 01 Dec 2007 01:02 GMT

> Im trying to write a small nio server. Its ServerChannel is configured
> for nonblocking operation. When a SocketChannel becomes readable I
> read the data into a ByteBuffer - but the data may not be complete so
> I cant start processing it right away - so where do I store the data
> untill I have a complete message? I use the same byte buffer whenever
> data becomes readable on a socketchannel.

Normally you will have a session context object that contains the
ByteBuffer for the channel, and other stuff, and this context object is
constructed and set as the key attachment when you accept the
connection. So you can get hold of it easily in the select loop when
OP_READ fires. If you don't have any other stuff for the session you can
make the ByteBuffer itself the attachment. But you must obviously have
one ByteBuffer per channel.

Reply to this Message

tbitzer@gmail.com - 04 Dec 2007 15:04 GMT

> > Im trying to write a smallnioserver. Its ServerChannel is configured
> > for nonblocking operation. When a SocketChannel becomes readable I
[quoted text clipped - 10 lines]
> make the ByteBuffer itself the attachment. But you must obviously have
> one ByteBuffer per channel.

Now im using the selectionKey.attach() to store data recieved on
the channel untill its complete - i was just hoping for some way to
avoid
copying data and creating new objects but i dont think it can be
avoided - and
i need to do some preprocessing to find out when i have a complete
message (cant
process on bytebuffer). The object im adding to attachment is just a
StringBuilder.
Another issue to deal with now is how/when to clean incomplete
messages attached to
selectionKeys that expire/never trigger again so i dont get a memory
leak.

Reply to this Message

Esmond Pitt - 06 Dec 2007 05:40 GMT

> i was just hoping for some way to
> avoid copying data and creating new objects but i dont think it can be
> avoided

It can be avoided if you make the attachment the ByteBuffer as I suggested.

> Another issue to deal with now is how/when to clean incomplete
> messages attached to
> selectionKeys that expire/never trigger again so i dont get a memory
> leak.

Don't select forever, select for a finite timeout, which might be say 10
minutes or so. Whenever this expires, i.e. select() returns zero, scan
the keyset of the selector (not the selected keys) and close any
channels which haven't had any recent activity. You will need to keep a
separate map of selection keys, or channels, to date last used.

Reply to this Message

Where to read NIO data to?

Free Magazines