Announcement

Collapse
No announcement yet.

Channel Response - TCP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Channel Response - TCP

    Mirth Version: 3.3.1.7856

    I've this scenario:

    Channel A:
    - Channel Reader
    - Send to Channel B (TCP Sender)
    - Ignore response unckeked
    - Response Timed Out = 5000
    - Keep Connection Open = Yes

    Channel B:
    - TCP Listener
    - JavaScript Writer Destination
    - Create ResponseMap('RespDest1', some xml)
    - On "Source Settings" Response = RespDest1
    - Keep Connection Open = Yes

    When i send some XML from A to B, B receive the message and on the Destination the Response is an xml like i create on 'RespDest1'.
    Channel A is waiting for response from Channel B and when timeout changes to idle. Inside Channel A on the message destinations is says "SENT: Message successfully sent, but no response received." But on Channel B it's says that the response is the ResponseMap i created!!!! How can i see the response sent by Channel B on Channel A??!!!!

    But in Channel B if i send the response to another channel, another TCP channel, it's sends the response and i'm able to see the XML response i want!

    Thanks
    Best Regards,
    Alex Neiva

  • #2
    Please post the channels you're using.
    Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

    Nicholas Rupley
    Work: 949-237-6069
    Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


    - How do I foo?
    - You just bar.

    Comment


    • #3
      Originally posted by narupley View Post
      Please post the channels you're using.
      I send the 2 channels...

      Thanks
      Attached Files
      Best Regards,
      Alex Neiva

      Comment


      • #4
        Well no wonder, you're using Basic TCP without any end-of-message bytes! In that configuration, the only way the listener can know that a message has finished being received is if the receive timeout is reached, or if the client closes the connection. This applies not only to the listener connector, but also the sender connector when waiting for a response. So if both the sender and listener have the same timeout set (e.g. 5 seconds), then typically the sender will close the connection before the listener has a chance to send the response back. You can increase the response timeout of the sender to something higher than the receive timeout of the listener in that case.

        Or, a better solution would be to use a protocol that has designated start/end frame bytes, like MLLP. That way the listener doesn't have to wait for any receive timeout; once it sees the ending byte sequence it immediately knows that a message has been received.

        So just change the transmission mode of both the listener and sender to MLLP. Then on the listener, switch the receive timeout back to 0.
        Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

        Nicholas Rupley
        Work: 949-237-6069
        Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


        - How do I foo?
        - You just bar.

        Comment


        • #5
          Originally posted by narupley View Post
          Well no wonder, you're using Basic TCP without any end-of-message bytes! In that configuration, the only way the listener can know that a message has finished being received is if the receive timeout is reached, or if the client closes the connection. This applies not only to the listener connector, but also the sender connector when waiting for a response. So if both the sender and listener have the same timeout set (e.g. 5 seconds), then typically the sender will close the connection before the listener has a chance to send the response back. You can increase the response timeout of the sender to something higher than the receive timeout of the listener in that case.

          Or, a better solution would be to use a protocol that has designated start/end frame bytes, like MLLP. That way the listener doesn't have to wait for any receive timeout; once it sees the ending byte sequence it immediately knows that a message has been received.

          So just change the transmission mode of both the listener and sender to MLLP. Then on the listener, switch the receive timeout back to 0.
          Thank you... it works! So simple... In my mind i was guessing it was the Transmition Mode to MLLP but then i was like "naaa it can't be"!!! well, thanks very much
          Best Regards,
          Alex Neiva

          Comment

          Working...
          X