Announcement

Collapse
No announcement yet.

Responding to TCP listener with data

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

  • Responding to TCP listener with data

    There are a number of posts about this in the forums but no conclusive answer. I'd like to post arbitrary data (not just an ACK) back to the sender of a message posted via TCP. Preferably this would be the same arbitrary data posted to a file destination.

    I've tried to grab the 'receiverSocket' variable in a transformer and manipulate it directly, but I get the 'ReferenceError: "receiverSocket" is not defined.' message. I've also tried generating the response in a JavaScript Writer destination and posting it to the output stream of the 'receiveSocket' there, no go.

    I'm using the latest Mirth (1.7.1) and am happy to experiment.

  • #2
    Re:Responding to TCP listener with data

    This thread is essentially the same problem you described:

    http://www.mirthproject.org/index.ph...4&catid=2#7204

    Comment


    • #3
      Re:Responding to TCP listener with data

      It does sound like the same problem. I had tried this before and didn't get it to work, and just tried it again mimicking the steps that you took, but Mirth did not respond with any data.

      I just ratcheted down the logging and saw this:

      Code:
      INFO  2008-09-25 08:39:21,873 
          [bf79ef41-8a6c-4aac-934c-01de433e9d29_source_connector._tcpEndpoint#378585825.receiver.1] 
          com.webreach.mirth.connectors.tcp.TcpMessageReceiver: TCP connection from /127.0.0.1:58326 
          on port 6661
      INFO  2008-09-25 08:39:42,406 
          [bf79ef41-8a6c-4aac-934c-01de433e9d29_source_connector._tcpEndpoint#378585825.receiver.2] 
          com.webreach.mirth.connectors.tcp.protocols.DefaultProtocol: SocketTimeoutException on 
          read() attempt.  Socket appears to have been closed: Read timed out
      I'm not closing my end of the socket, but it seems like Mirth isn't seeing the end-of-message sequence I'm sending (two carriage-returns) and thinks the message isn't 'done', then waits until one side or the other hits a timeout. So it could be that Mirth takes what it's got at that point and continues along its merry way, but there's no socket to write the response to since it's already timed out.

      So, it seems like I need to tell Mirth when I'm done sending data. I don't see a place in the Source configuration where I can specify an EOM sequence, and there doesn't seem to be any docs about this. What did you do?

      Comment


      • #4
        Re:Responding to TCP listener with data

        I've used this configuration with an LLP listener. In this connector you can define the "end of segment" and "end of message" characters.

        I dont know how to manage this with a TCP listener.

        Hope that helps.

        Comment


        • #5
          Re:Responding to TCP listener with data

          I was able to get this working properly, thanks for pointing me
          in the direction of the LLP Listener. I see now that the TCP
          Listener is a dead end -- if Mirth cannot recognize the end of
          message, there's no way for it to process what it's got and then
          respond with your arbitrary data. (I guess you could muck about
          with read timeouts and make your client longer than your server,
          but that seems fragile.)

          Anyway, for future readers I wanted to post how I got this
          working. I know such a post would have saved me a number of
          hours.

          1) Setup your Channel source with a LLP Listener;
          the following settings seemed most relevant:

          [ul]
          [li] Process Batch: Yes[/li]
          [li] LLP Frame Encoding: Hex (otherwise, for example, Mirth will look for a literal '0x0B' sequence rather than a vertical tab character)[/li]
          [li] Start of message char: 0x0B[/li]
          [li] End of message char: 0x1C[/li]
          [li] Use Strict LLP Validation: Yes[/li]
          [li] Encoding: Default[/li]
          [li] Send Ack: Respond from ScriptDestination ('ScriptDestination' is defined below, so you'll need to come back here after the next step to define this)
          [/ul]

          The start/end of message characters may have been the defaults,
          but since I control both the client and the server I could gauge
          whether they'd occur in real-world messages. YMMV.

          2) Define the following destinations:

          [ul]

          [li] File Writer 'FileDestination' - this just writes an XML document out the filesystem for independent verification. It's not strictly necessary.[/li]

          [li] JavaScript Writer 'ScriptDestination' - this writes arbitrary data (which happens to also be an XML document) to the response map so the LLP Listener can pick it up for the acknowledgement.[/li]

          [/ul]

          Based on other posts in the forum I originally had the
          ScriptDestination doing this:

          Code:
          var myResponse = "some arbitrary data";
          responseMap.put( 
              'ScriptDestination', 
              ResponseFactory.getResponse( myResponse ) );
          But this resulted in a ClassCastException (cannot cast Response
          to java.lang.String). So I replaced the above with:

          Code:
          var myResponse = "some arbitrary data";
          responseMap.put( 
              'ScriptDestination', 
              myResponse );
          And this worked!

          3) I did not define a post-processor script as other forum posts
          had mentioned, since the activity they defined was already done
          in the 'ScriptDestination'.

          Hope this helps someone else.

          Comment


          • #6
            Re:Responding to TCP listener with data

            Congratulations!

            I've never worked with TCP listeners, maybe they don't undestand the EOM until the client disconnects?

            About your guide, I'll recommend you to post it in the wiki section, it will be easier to find it (better than searching in old posts).

            See you!

            Comment

            Working...
            X