Where to read NIO data to?

[meselfo]

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.

 

[Crouchez]

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.

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

 

[Esmond Pitt]

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.

 

[tbitzer]

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.

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.

 

[Esmond Pitt]

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.