The HL7 Codec works on TCP messages, not UDP. On the other hand I don't think that the codec really depends on that. Note that HL7 messages have specific begin and end bytes that make it rather easy to cumulate the parts.
Christian 2012/12/3 Claus Ibsen <claus.ib...@gmail.com>: > 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
