No announcement yet.

Connection timed out (Read failed) Error on Mirth Channel with TCP Listener

  • Filter
  • Time
  • Show
Clear All
new posts

  • Connection timed out (Read failed) Error on Mirth Channel with TCP Listener

    Mirth 3.9.1

    I have a mirth channel where we are receiving HL7 messages using TCP Listener as Source,
    • Queue Buffer size - 1000
    • Process Batch - No
    • Max Processing Thread - 100
    • Max Connections - 500
    • Receive Timeout - 0
    • Keep Connection Open - Yes
    • Respond on New connection - No

    However I am continuously seeing errors as,

    com.mirth.connect.connectors.tcp.TcpReceiver: Error receiving message (TCP Listener "Source" on channel xxxxxxxxxx). Connection timed out (Read failed)
    307722- at java.base/ Method)

    Sender system also complaining about they are getting these time out errors.

    We have approx. 200K messages being received in a day. Can someone please help with with the correct settings I can use to fix these time out errors.






    Last edited by MirthNewB610; 06-13-2022, 11:08 PM.

  • #2
    Don't tag a list of people please.

    I think in your case you will need to fire up some network tools to determine the problem.

    But I would reduce both threads and max connections quite a bit, e.g. 20x20.

    Also your destination queue settings matter here also.

    Last edited by pacmano; 06-13-2022, 09:13 AM.
    Diridium Technologies, Inc.


    • #3
      Also statements like "We have approx. 200K messages being received" are useless without a timeframe. Is that a backlog? Is that per hour? etc.
      Diridium Technologies, Inc.


      • #4
        Thanks pacmano for the response.

        Approx. 200K messages are being received in a day from source system and we miss many due to this time out error.

        Also can you please explain as how reducing both (Max connections and Max processing threads to 20 x 20) will help.

        Doesn't it require more no of threads/connections as the messages are not been able to read in time and getting timed out.
        Last edited by MirthNewB610; 06-14-2022, 01:25 AM.


        • #5
          That is a small number of messages. Mirth can easily handle millions a day.

          You need to check network topology problems in your case. That might be VPN and/or firewall level configuration that are breaking the connection unintentionally.

          As for queue settings. Firstly be aware that message order is not guaranteed with queues. That can be very bad depending on your use case. As for the numbers you used and my suggestion to use less, that is from experience. After some relatively low number of queue threads performance does not change by making that number higher, you need to find the number that works well for you.
          Last edited by pacmano; 06-14-2022, 09:06 AM.
          Diridium Technologies, Inc.


          • #6
            May be start with "Don't Panic"
            HL7v2.7 Certified Control Specialist!


            • #7

              Any other suggestion?