Connections number (TCP_IP MLLP)

[StickyBandit]

Why does mirth hold onto these connections? So my guess is that the image attachment shows 112 but actually there are only 2. 110 of them the client must have timed out a long time ago and
Mirth Connect just won't free them. I have to restart mirth connect to get that number back to 0. Something does not seem right about this. If the client time's out because the message took too long, mirth connect should just recover and move on.... Confused.

Mirth Connect Server 3.10.0
Built on November 5, 2020
Java version: 1.8.0_181

[pacmano]

I would check netstat locally on the server and see if you have some funky timeout states.

[StickyBandit]

Also is there a way to use SSL on a TCP_IP listener?

[pacmano]

What is a tcp reader? You mean a tcp listener?

[StickyBandit]

corrected

[pacmano]

The SSL extension does this out of box. You can also offload it to stunnel which runs on both Windows and Linux.

[StickyBandit]

Is the SSL extension free or something we purchase?

[pacmano]

It is included with the core extension pack. It is not free but in my opinion very reasonable

[StickyBandit]

Our hosting server guys didn't know what funky timeout's meant and has not responded in regard to that.

[agermano]

Is there a vpn/stateful firewall between the client and server? If the firewall is dropping the connection because it's been idle for too long, the mirth server will never get a message that the client wants to close the connection, and will leave it open, because it has no way of knowing that the client isn't able to send on that connection anymore.

Have you tried setting the Receive Timeout on your TCP Listener to something besides 0 to see if that makes a difference?

[StickyBandit]

We have that set to 70000. 70 seconds. Still mirth connect never seems to let go of the connection. This setting is more about waiting to receive a message, not about responding.