Mirth Community

Mirth Community (http://www.mirthcorp.com/community/forums/index.php)
-   Support (http://www.mirthcorp.com/community/forums/forumdisplay.php?f=6)
-   -   Permanent Connection with TCP Sender (http://www.mirthcorp.com/community/forums/showthread.php?t=217429)

gkittlaus 07-28-2017 02:29 AM

Permanent Connection with TCP Sender

is there a way to keep the connection open between a MirthConnect TCP Sender to another Server?
The Server is monitoring its own Socket and always states a warning after Mirth is closing the Socket when all messages have been sent. "Keep connection open" is only working if there are still messages to be sent.

Thanks in advance!

kirbykn2 07-28-2017 06:49 AM

Set "Keep Connection Open" to yes
and "Send Timeout" to 0

gkittlaus 08-01-2017 12:08 AM

Thanks! :)

djantzen 04-16-2018 04:23 PM

Clarifying question about this behavior
If the timeout is hit and the connection is closed, what will cause it to reopen? Will new messages prompt a reconnect?


narupley 04-17-2018 07:03 AM


Originally Posted by djantzen (Post 263338)
If the timeout is hit and the connection is closed, what will cause it to reopen? Will new messages prompt a reconnect?


Yes, once the next message comes in the connection will be opened again.

djantzen 04-17-2018 07:22 PM

Thank you for the clarification!
What we are seeing is that one Mirth instance forwarding MLLP messages to a second Mirth instance gradually slows down and grinds to a halt, enqueuing messages on the first instance. We are on version

We have a simple example that demonstrates this in a local development environment. It appears that enabling the 'Keep Connection Open' option will cause the failure to occur after several thousand messages.

However, when we opt *not* to keep the connection open, it takes several tens of thousands of messages to be sent before the slowdown occurs and the queue expands. So, it's better, but still a problem.

To drain the queue we have to redeploy the channel to the sender Mirth instance, or restart it entirely.

Can you provide any suggestions about what might cause such behavior?

Thanks for your time,
David Jantzen

kirbykn2 04-18-2018 08:14 AM

Underlying Network issue, queue settings, perhaps an issue delivering to the final destination....

Can you post your channels or at least a screen shot of the source and destination settings for each?

Has this issue always happened, or did something change?

djantzen 04-23-2018 01:02 PM

And I have to retract most of that...
It appeared at first that there was a difference between keeping the connection open versus reopening each time, but that did not turn out to be consistent. We see a backed up queue sporadically, regardless of the setting or the Send Timeout value.

It may indeed be an underlying networking issue. The Mirth servers actually run within their own Docker containers, and that additional abstraction layer may be hiding the problem. Something we fixed in this process was a DNS configuration in the containers that was causing 4 second delays in any network operation involving address resolution. That may yet turn out to be the root cause here, but again, it's not yet reproducible.

All times are GMT -8. The time now is 12:49 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation