camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: HL7 ProtocolCodec truncates long HL7 messages
Date Fri, 24 Apr 2009 15:45:53 GMT
Hi Christian

No that is fantastic. We would love to incorporate your findings into
the camel-hl7 component.

So if you are willing to donate then please create a JIRA ticket and
attach your work.

On Fri, Apr 24, 2009 at 5:39 PM, christian ohr <> wrote:
> Hi there,
> in the current implementation of the HL7 component, HL7v2 messages that
> exceed a certain size (I guess it's related to the TCP packet size, 1024
> bytes on my machine) are split into two or more exchanges. The second (,
> third, forth, ...) exchange body starts somewhere in the middle of the
> message, which makes no sense for any HL7v2 parser.
> The reason for this is that in general it takes MINA more than one
> messageReceived() to read a complete message. Instead of waiting for further
> data, the current implementation of the HL7MLLP Decoder simply creates an
> exchange for every chunk of data.
> I spent some time to rewrite the decoder using MINA's
> CumulativeProtocolDecoder (see attached). Furthermore, the decoder is smart
> enough not to rescan the message received so far as a whole but only the
> data that was added during the latest RECEIVE. Finally, everything is split
> up into factory, decoder, and encoder (the latter class remained mostly
> unchanged).
> I'm embarrassed to admit that no unit test are included :blush:, but in my
> environment the implementation works both for small messages and for message
> of size > 65k.
> I'd like to ask to add this (or something similar) in the upcoming Camel
> release.
> cheers
> Christian Ohr
> --
> View this message in context:
> Sent from the Camel - Users (activemq) mailing list archive at

Claus Ibsen
Apache Camel Committer

Open Source Integration:
Apache Camel Reference Card:

View raw message