Thanks for the response.
I actually figured out my problem I was stuffing and unstuffing data in my
pojo, It looks like that's the problem I can't believe how I totally forgot
about that.
As you have mentioned the following code for my decoder will work ok for LAN
scenarios. It will be problematic if I receive 78 bytes one by one. How can
I handle that scenario if message reaches server in parts? There can be many
fragmented messages that might be coming from different clients. How can my
server figure out which message belongs to which historical message and
merge them correctly to make a complete message? How can the following code
be improved? Is there a working example that I can take a look at?
public class MessageDecoder extends CumulativeProtocolDecoder {
protected boolean doDecode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) throws Exception {
if (in.remaining() >= 31) {
//Has value of 78
int len = in.remaining();
byte[] stream = new byte[len];
in.get(stream);
System.out.println(len);
Message message = new Message(stream);
out.write(message);
return true;
} else {
return false;
}
}
}
On Thu, May 14, 2009 at 6:15 PM, Emmanuel Lecharny <[email protected]>wrote:
> Erinc Arikan wrote:
>
>> Hi,
>>
>> I just started working on MINA last week, I am trying to convert a gateway
>> application to MINA - ACTIVEMQ project. I am really impressed the
>> simplicity
>> MINA brings.
>>
>> After this irrelevant introductory part, Here's my problem:
>>
>> My clients connect to the server using a tcp connection.
>>
>> I created my own protocolfilter where I specify my encoder and decoder.
>> Decoder on the server side what I care about most, because that's what I
>> will pass into activemq and process.
>>
>> Only filters that I use are my custom protocolfilter and loggingfilter,
>> the
>> problem lies here: if my client sends a packet of length 78 bytes, decoder
>> in my protocolfilter receives a 0 padded 72 bytes of data. When I strip
>> 0's
>> and and reach end of the message delimiter byte, I realize that what I
>> receive is 72 bytes long. And it somehow matches crc16 calculation from
>> the
>> message but still some bytes are missing. Same thing happened when my
>> message has size 40 and decoder received 35 bytes. I don't know what I am
>> doing wrong but since CRC values match I feel like there is something
>> wrong
>> on my side. Unfortunately I couldn't find an answer to this question on
>> documentation.
>>
>> Any help will be greatly appreciated.
>>
>>
>
> Remember that there is no guarantee that your message will arrive in one
> chunk of exactly 78 bytes. You may as well receive 78 messages containing
> one single byte. You have to accumulate them until you get what you need.
>
>> Erinc
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
