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

[MirthNewB610]

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).
307661:java.net.SocketException: Connection timed out (Read failed)
307722- at java.base/java.net.SocketInputStream.socketRead0(Native 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.

Thanks


narupley

agermano

jackwhaines

@albertosaez


pacmano

[pacmano]

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.

[pacmano]

Also statements like "We have approx. 200K messages being received" are useless without a timeframe. Is that a backlog? Is that per hour? etc.

[MirthNewB610]

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.

[pacmano]

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.

[siddharth]

May be start with "Don't Panic"

[MirthNewB610]

narupley

Any other suggestion?