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