On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > So have you tried with setting auto expand = false in camel-mina2, and > see if that fixes the issue for you? > >
Hi Claus, Thanks for your comment. I have conducted more tests to trace the root cause. Unfortunately, setting auto expand to false did not fix the problem because such flag is needed when dealing with unicode characters. I once tried to set it to false to only observe BufferOverflowException. When debugging, I found out that Mina2Consumer received the message n-times depending on the fragmentation (doDecode is called n-times) if a class extending CumulativeProtocolDecoder is used as the decoder in a custom codec. Yet, the content in each call is exactly the same, which is the first 2048 bytes of the message sent. As a remark, session.getTransportMetadata().hasFragmentation() is false, which was different with my expectation. Additionally, the call is only once when the received message is decoded using the default codec, i.e. Mina2UdpProtocolCodecFactory. In that call, only the first 2048 bytes are received. I come into a proposition that the problem can be caused by different session management mechanism in Camel Mina 2 compared with that of Camel Mina. Yet, I haven't been able to refine and isolate the exact part of the code causing such behavior. I'm not that familiar with the codebase and I'm not quite sure if it's a feature in the new component. I'd be glad for further clarification from others with more competency in this matter. Regards, Mike
