[IDEA] Validate Response Dependability

[mdiller4]

Is your feature request related to a problem? Please describe.
We have an issue where even though we have Queueing enabled and Validate Response set to Yes, if the other vendor drops their side of the connection, the next message goes to a SENT status and says "Message Successfully Sent, but received no response." The next message following that will queue. So, we are losing messages when this happens. We do have Keep Connection Open set to Yes.

Describe your use case
The expectation is that Validate Response ensures message delivery.

Describe the solution you'd like
It should recognize that the connection is down and that there was no response and queue the message.

Describe alternatives you've considered
Currently we are using the Check Remote Host option to keep this from happening, however this is not feasible on a high volume interface.

Additional context
I did contact support, the case# is 07056756. They confirmed that Mirth is working as designed, but this is not dependable as we are losing messages and are not notified when it happens. We also provided packet captures indicating we are not losing packets. This issue can be reproduced every time by starting both sides and having the 3rd party take their connection down. The only reason we found out this was happening was end users reporting they were missing messages in the other system.

[jonbartels]

What connection type and what message type?

I cannot think of a solution or workaround, but maybe investigating how the "Check Remote Host" code works could make it more efficient for high volume connections.

Can you say what interface engine is on the other side of the connection? I doubt this is vendor specific but more data can help.

Is this issue reproducible between two Mirth instances?

[mdiller4]

The Connection Type is TCP/IP. The message type is an X12 message for this particular interface that I found the problem on.

We had Check Remote Host turned on for some of our interfaces and had to turn it off because it was causing them to back up in the queue a couple thousand. They were still processing, just really slowly ,so we had to turn it off.
For this particular interface, it's not super high volume, so I have that option turned on for now.

I am not sure what engine the vendor is using, but I can reproduce this issue using a Cloverleaf engine and I can also reproduce it from Mirth to Mirth.

Thanks,

Megan

[lmillergithub]

@mdiller4 I am trying to recreate what you are describing and I am unable to. Can you please describe the setup you are using to reproduce from Mirth to Mirth?

[mdiller4]

I am adding an attached file with the setup of my Destination. I set it up so both sides are connected and message sends successfully. I then disconnect the other side and then send a message through and immediately the message says it was sent, but did not receive response.
Channel.docx

[lmillergithub]

When I run the exact scenario above, the second message gets QUEUED, which is what should happen. I noticed that you have a script running on that channel, is something in there that cause your issue? I was thinking this was a timing issue. Something like if the message made it to the receiver but the connection closed before it sent the response - but I am unable to recreate that as well.

[mdiller4]

The script just contains the IP and Ports for our different environments. That shouldn't cause an issue. The same thing happens to me. The 2nd message gets queued, but the first message immediately says Sent but no response received. Also, since the other side is down, I don't think it would receive or send a response for anything. I have also confirmed with our 3rd party vendor that when this happens, they are not receiving the message.