On Mon, Dec 3, 2012 at 10:44 AM, Christian Ohr <christian....@gmail.com> wrote: > 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. >
Ah yeah good point about the markers. > 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 -- 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
