Announcement

Collapse
No announcement yet.

Channel unable to handle Socket Reset exception

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

  • Channel unable to handle Socket Reset exception

    Hi All,

    The LLP receiver whom my LLP Sender is sending messages, uses a TCP RST packet to close the connection at a timeout. Although dirty at receiver end, but we have to work with it for now. The issue this: To recover from this, I have to redeploy the channel, each time Socket reset exception is thrown. So I would like to know is there a better way to recover from this without needing to redeploy the channel.

    I have Keep Connection Open in LLP Sender set to : Yes

    My mirth version is : 2.2.2.6388
    Java version 1.7.0_25

    Its Microsoft Windows 8 server.

    Any pointers are appreciated.
    -Thanks in advance

  • #2
    Why do you have to redeploy the channel? I'm assuming you don't have control over that LLP Server, but how exactly is that affecting your LLP Sender?
    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
      I am not able to reestablish connection without redeploying the channel. This is different from "Connection refused" where Mirth channel is automatically able to reconnect in next try. However when encountered with socket reset exception it remains in that state unless I redeploy.

      Comment


      • #4
        Originally posted by fasterlight View Post
        I am not able to reestablish connection without redeploying the channel. This is different from "Connection refused" where Mirth channel is automatically able to reconnect in next try. However when encountered with socket reset exception it remains in that state unless I redeploy.
        Does the server only allow one client socket at a time? If so, you may be running into a situation where the socket is still in TIME_WAIT on the server side, and so you can't reconnect until that gets cleaned up. When that happens, instead of redeploying the channel have you tried just waiting a while and then sending another message?
        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
          You are right, Server only allows one connection at a time. The mirth channel I have continuously keep sending the messages unless its successful, so I don't WAIT and that actually may be that's why continually recurring Socket reset exception are not allowing it to clean up. I will see if I can find out what's the TIME_WAIT config at server end and then match sender to retry after that time only. Does that make sense ?

          Comment


          • #6
            Originally posted by fasterlight View Post
            You are right, Server only allows one connection at a time. The mirth channel I have continuously keep sending the messages unless its successful, so I don't WAIT and that actually may be that's why continually recurring Socket reset exception are not allowing it to clean up. I will see if I can find out what's the TIME_WAIT config at server end and then match sender to retry after that time only. Does that make sense ?
            Sounds like a plan; you would probably want to use the Reconnect Interval for that (in 3.x it would be the Retry Interval on the Queue/Retry Settings).
            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

            Working...
            X