camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: HL7 component release connection problem
Date Fri, 11 Feb 2011 05:23:46 GMT
Hi

Can you open a JIRA ticket and attach a sample of the HL7 stream you send?
Then we can use that to check into the issue.

Do you test HL7 message only contain 1 startbyte and 1 end byte
sequence, eg like this:

a)
- start byte
- msg 1
- msg 2
- end bytes

b)
Or do you do
- start byte
- msg 1
- end bytes
- start byte
- msg 2
- end bytes


If you do a) is there some byte which separate msg 1 from msg 2?


On Fri, Feb 11, 2011 at 4:04 AM, hoopzhou <hoopzhou@gmail.com> wrote:
>
> 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.
>



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message