camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Ohr <christian....@gmail.com>
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.

Christian

2012/12/3 Claus Ibsen <claus.ibsen@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
> <mikaelf@gmail.com> wrote:
>> On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <claus.ibsen@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: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message