Announcement

Collapse
No announcement yet.

ACK timeout reporting

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

  • ACK timeout reporting

    Hello,
    I have configured an LLP sender with a 30000 ms ACK timeout (Ignore ACK is off, Process HL7 ACK is on).

    On the 'Channel Messages screen I'm seeing the following:

    2008-11-20 11:57:12.948 | TEST_LLP | ADT-A01 | Test Hospital | ERROR
    2008-11-20 11:57:12.940 | Source | ADT-A01 | Test Hospital | TRANSFORMED

    When I click on the top line and then the 'Errors' tab I see:

    ERROR-408: MLLP Connector error
    ERROR MESSAGE: Timeout waiting for ACK

    Now judging by the Date difference between the log messages, it appears as if it's waited only .008 seconds before timeout, even though it is configured to wait up to 30 seconds.

    Am I interpreting wrongly? Is this an issue with the logging? Is it indicative of the receiving end closing the channel? Bad setting for ACK timeout?

    thanks
    Steve

  • #2
    Re:ACK timeout reporting

    HUMB.

    I thinkd TMO ack is fine. Perhpas the logger time mark the moment the message is transformed, not the moment the error is set.

    Comment


    • #3
      Re:ACK timeout reporting

      HUMB?

      The *real* issue I'm dealing with are "fast" timeouts waiting for ACKs.
      I've got the timeout set to 5 minutes, and have tried both keeping the connection open and not keeping the connection open. However, the timeout error (ERROR-408) gets posted almost immediately after the message is sent (which is why I was wondering about the time printed in the error).
      Any guess as to why it would get a timeout so fast? Is this indicative of the connection getting closed somewhere prematurely?

      thanks again,
      Steve

      Comment


      • #4
        I know this thread is months old, but I am experiencing an identical issue to this. We have our ACK timeout set for several minutes, but as soon as I send a message I get an immediate error with the error description that it timed out waiting for ACK. Found this old thread with no resolution and was curious to see if there was any additional input regarding this problem. Thanks.

        Comment


        • #5
          I have also experienced the "Timeout waiting for ACK" error. Often the error is caused by something other than waiting for ACK. For example, if the connection is dropped by the receiving system before Mirth gets an ACK you would get this error. Modifying the ACK timeout in Mirth will not make a difference in that case. I can't say for sure what you need to do to fix this problem since it is dependent on the receiving system. Try modifying some of the settings such as "Keep connection open" and see if that helps. Also check the specs for the receiving system and see if that provides any clues.
          Daniel Svanstedt
          Software Engineer
          Mirth Corporation

          Want professional services, support, and enterprise or virtual appliances? It's all available from the Mirth Corporation:
          Mirth Support | Mirth Training | Mirth Appliances | Online Training | Developer Q&A

          Don't forget, Mirth Support gives you access to all of our online training videos, and silver support gives you access to developer Q&As!

          Comment


          • #6
            I've filed a bug that will help with this issue. Please vote for:

            http://www.mirthcorp.com/community/i...wse/MIRTH-1073

            Comment


            • #7
              In our situation I enabled persistent queuing and this seems to have resolved the problem. As far as what was causing the errors in the first place I'm not sure, though I can confidently say it was not an error due to a timeout waiting on the ACK. I'll report back if the problem resurfaces.

              Comment


              • #8
                When you wrote "enabled persistent queuing...resolved the problem" do you mean:

                "Changing the LLP Sender's destination parm 'Use Persistent Queues:' radio button from No to Yes resolved the problem"?

                Comment


                • #9
                  Phil, yes that's correct. We previously had the radio button set to No, and after setting it to Yes we see that messages going across the channel may go to queued for a moment, but so far all have sent successfully with zero "Timeout waiting for ACK" errors.

                  Comment


                  • #10
                    I had the same issue and changing the channel to "Use Persistent Queues" fixed my problem.

                    Comment


                    • #11
                      I have been having this same issue and have voted for the bug MIRTH_1073. I am reluctant to enable Persistent Queues since I dont' know what the affect will be. Questions:

                      * will new messages just stack up behind the queued message until it goes?
                      * If the queued message never goes, will all messages stop?
                      * Will channel synchronization work properly with this setting?

                      Thanks in advance.

                      Comment


                      • #12
                        Just a hint ... you get the "ack timeout" error also when the 3rd party system is closing the socket connection in between two message transfers ...

                        I would suggest to diagnose the socket data transfer using e.g. Wireshark and verify if/when the acknowledgements arrive.

                        Best Regards

                        Nico
                        Nico Vannieuwenhuyze

                        Amaron.be

                        Comment


                        • #13
                          Originally posted by nicovn View Post
                          Just a hint ... you get the "ack timeout" error also when the 3rd party system is closing the socket connection in between two message transfers ...

                          I would suggest to diagnose the socket data transfer using e.g. Wireshark and verify if/when the acknowledgements arrive.

                          Best Regards

                          Nico
                          I just found the following bug report (MIRTH-1442) that describes my exact issue...

                          http://www.mirthcorp.com/community/i...wse/MIRTH-1442

                          Sure would like a solution without upgrading to a beta product. Does anyone have any ideas? Is the code fragment that is included in the bug report a workaround for Mirth v1.8.2? or is that a code fragment for v2.0.0?

                          The other part of the problem though is still a TCP issue but why doesn't mirth actually wait the 5 seconds for the ACK?

                          Comment

                          Working...
                          X