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 http://gforge.openehealth.org/gf/project/ipf/ http://www.nabble.com/file/p23219074/HL7MLLPCodec.zip HL7MLLPCodec.zip -- View this message in context: http://www.nabble.com/HL7-ProtocolCodec-truncates-long-HL7-messages-tp23219074p23219074.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
