Hi The camel-hl7 component has a mina codec that works with hl7 message formats. And I think there is some logic in there to "assemble" udp messages that is larger than 2048.
I remembered some patches we got years ago about something related to this. Maybe take a peek in the camel-hl7 source code. On Tue, Nov 27, 2012 at 6:50 AM, Mikael Fernandus Simalango <mika...@gmail.com> wrote: > 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 -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
