camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Ohr <>
Subject Re: [camel-mina2] Bug in default UDP codec (Mina2UdpProtocolCodecFactory)?
Date Mon, 03 Dec 2012 09:44:25 GMT
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.


2012/12/3 Claus Ibsen <>:
> 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
> <> wrote:
>> On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <> 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:
> Web:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:

View raw message