Mirth Connect 4.0.1 Released!

Mirth Connect 4.0.1 is now available as an appliance update and on our GitHub page. Mirth Connect 4.0.1 is a patch release containing a bug fix which includes fixing a Jetty keystore regression that caused Connect servers using a PKCS12 keystore containing a wildcard certificate and/or a certificate with a SAN to throw an exception on startup. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

Creating ACK from a TCP Listener

  • Filter
  • Time
  • Show
Clear All
new posts

  • Creating ACK from a TCP Listener


    I set up Mirth on 2 machines (A and B)



    A's channel reads a file (in.txt), sends it via tcp to B
    B's channel reads the TCP input and writed is to a file (out.txt)

    When I look at the Channel Messages for A's channel, the destination has a variable called Destination 1 with a value of SUCCESS: Empty Response.

    How do I get B to send an ACK message to A and have the "Destination 1" variable have a value of what I put in the ACK message?


  • #2
    Re:Creating ACK from a TCP Listener

    Well. I have found that LLP Listener can receive a TCP message successfully. The LLP Listener has configurations available for the ACK message in the listener interface.

    So, I have it configured to send the ACK back to the tcp sender (see attachment). However, I'm still getting the "SUCCESS: Empty Response" from the sending channel (machine A). How do I verify that the ACK message is getting back to the TCP Sender?


    • #3
      Re:Creating ACK from a TCP Listener

      MyDestination_MachineB.xml (4374 bytes)


      • #4
        Re:Creating ACK from a TCP Listener

        MySource_MachineA.xml (4002 bytes)


        • #5
          Re:Creating ACK from a TCP Listener

          Instead of having a TCP listener on machine B, I made it an LLP listener. This seems to work, since the LLP generates the ACK for me and sends it back to machine A. I also had to set the timeout variables to something other than 0 on the sender and listener.

          Not sure if this is the correct way to send ACK back on TCP or not. Does anyone have any input?