You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2012/12/03 10:27:00 UTC
Re: [camel-mina2] Bug in default UDP codec (Mina2UdpProtocolCodecFactory)?
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
<mi...@gmail.com> wrote:
> On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <cl...@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
Re: [camel-mina2] Bug in default UDP codec (Mina2UdpProtocolCodecFactory)?
Posted by Mikael Fernandus Simalango <mi...@gmail.com>.
On Mon, Dec 3, 2012 at 6:58 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Dec 3, 2012 at 10:44 AM, Christian Ohr <ch...@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.
>
We decided to fail back to Camel Mina as the base component. The udp
endpoint of our component behaves as expected when running on top of
Camel Mina. We, however, keep the issue open and will revisit later
when we can afford more time to investigate session management and
packet reassembling in Camel Mina 2. I'm expecting that I/O
performance will be better in Mina 2 and Camel Mina 2. So, switching
to Camel Mina 2 is still in the trajectory.
Thanks to Claus and Christian for the inputs and comments.
Regards,
Mike
Re: [camel-mina2] Bug in default UDP codec (Mina2UdpProtocolCodecFactory)?
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Dec 3, 2012 at 10:44 AM, Christian Ohr <ch...@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 <cl...@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
>> <mi...@gmail.com> wrote:
>>> On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <cl...@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
--
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
Re: [camel-mina2] Bug in default UDP codec (Mina2UdpProtocolCodecFactory)?
Posted by Christian Ohr <ch...@gmail.com>.
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 <cl...@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
> <mi...@gmail.com> wrote:
>> On Sat, Nov 24, 2012 at 5:29 PM, Claus Ibsen <cl...@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