You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by afoss <af...@actsolar.com> on 2007/10/21 15:54:21 UTC
Sequential rcv buffer processing...
I'm new to Mina, so apologies, if this is a really basic ?, but I'm stuck.
Our application rcv's lot's of small messages, that must be re-assembled if
they cross boundaries of the rcv buffer and they must be processed in order.
Here's what happens;
messageReceived is happily processing a 2048 byte buffer which contains the
first 250 messages, plus a partial of msg 251.
The remainder of msg 251 plus another 2030 bytes of messages arrives and a
new messageReceived, tries to process this buffer, but the first buffer
isn't done to have rcv'd and saved the first portion of msg 251, so they can
be re-assembled w/ the second buffer and handled properly.
--
View this message in context: http://www.nabble.com/Sequential-rcv-buffer-processing...-tf4666135s16868.html#a13329256
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Sequential rcv buffer processing...
Posted by Niklas Therning <ni...@trillian.se>.
afoss wrote:
> I'm new to Mina, so apologies, if this is a really basic ?, but I'm stuck.
> Our application rcv's lot's of small messages, that must be re-assembled if
> they cross boundaries of the rcv buffer and they must be processed in order.
>
> Here's what happens;
>
> messageReceived is happily processing a 2048 byte buffer which contains the
> first 250 messages, plus a partial of msg 251.
>
>
> The remainder of msg 251 plus another 2030 bytes of messages arrives and a
> new messageReceived, tries to process this buffer, but the first buffer
> isn't done to have rcv'd and saved the first portion of msg 251, so they can
> be re-assembled w/ the second buffer and handled properly.
>
You should have a look at the protocol codec tutorial:
http://mina.apache.org/tutorial-on-protocolcodecfilter.html
I think that will help.
--
Niklas Therning
www.spamdrain.net