[IDEA] Validate Response Dependability

[mdiller4]

[IDEA] Validate Response Dependability

[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.