I used startbyte 0x0b ,endByte1 0x1c and endByte2 0x0d in my test HL7
message.


IPF groups member says that "except the ghl7() part of the route I don't see
anything else which is IPF specific. Can you try with the Camel's hl7()
instead of the ghl7() to verify the same behavior?"

So I build a new test route follow the Samples in
http://camel.apache.org/hl7.html like below:

from("mina:tcp://0.0.0.0:5800?sync=true&codec=#hl7MLLPCodec")
      .unmarshal(hl7)
      .to("mock:unknown")
      .end()
      .marshal(hl7);

This route move IPF out.

And I run the Scenario II (no release connection case) again , the "message
append" still appears.

I try to read the source code of HL7MLLPDecoder.java:
"
 private void writeString(IoSession session, ByteBuffer in,
ProtocolDecoderOutput out) {
        DecoderState state = decoderState(session);
        if (state.posStart == 0) {
            LOG.warn("No start byte found, reading from beginning of data");
        }
        // start reading from the buffer after the start markers
        in.position(state.posStart);
        try {
            String body = in.getString(state.length(),
charsetDecoder(session));

            if (LOG.isDebugEnabled()) {
                LOG.debug("Decoded HL7 from byte stream of length " +
state.length() + " to String of length " + body.length());
            }
            out.write(body);
            // Avoid redelivery of scanned message
            state.reset();
        } catch (CharacterCodingException e) {
            throw new RuntimeException(e);
        }
    }"

It seems to write all bytebuffer to body. Is it the cause? Sorry for that I
am not very familiar with Java NIO. 

-- 
View this message in context: 
http://camel.465427.n5.nabble.com/HL7-component-release-connection-problem-tp3378827p3380565.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to