I can give you some solace but not necessarily for the reason that the interface listener is the problem.
Even Cloverleaf behaves this way when you are faced with unreliable networks, firewall, and VPNs.
I have most often found the items I just mentioned are the cause for the behavor you are describing.
It is a common problem when an integration is terminated abruptly the listener still thinks it is connected and will refuse a connection until recycled.
One common workaround on the cloverleaf side has been to configure the cloverleaf listener for multi-server to allow N connections to occur, which isn’t applicable in your case since Cloverleaf is the sender.
You could ask the vendor if they have a multi-server feature on their listener, especially if faced with those hostile monkeys (network, VPN, firewall) in the middle.
Another poor solution that sometimes get used is to regularly cycle the listener especially if nothing received for a while.
I’ve come to like but yet to have many of these work arounds in place is to send a dummy keep-alive message (a real message modified to be a dummy patient) that is sent say once every 1-5 minutes.
Then listener can check proactively and frequently for a message received without generating false alerts.
If the dummy message can be genreated by an automated keyboard robot using the source application then even better because the down stream application can constantly check for the expected dummy transaction and all aspects of the integration including both applications are now being monitored indirectly.
Granted this last soultion is not effiecient or elegant but seems to be a solution that those hostile monkeys in the middle keep pushing me towards.
Russ Ross
RussRoss318@gmail.com
.
