Then the channel will respond with an ACK immediately after receiving the message (and committing the raw data to the database). And also, if something external is causing these networking issues, you'll still see the same errors and symptoms (though perhaps slightly less often).Īnother thing that may help is to turn the Source Queue on, and set the response to Auto-Generate. On the Mirth Connect side the connection will be closed after the first message, regardless of whether the socket buffer contains more data. You'll still likely see some errors on the client side because it'll probably still attempt to send multiple messages in bursts over the same connection. Turning Keep Connection Open off may help because that will force the client to open a completely new connection for each message. This may be more evidence of something external (firewall, router, etc.) causing these networking issues. So the retransmissions are not just from the Mirth side to remote, but both ways, and happening at the same time. Not 100%, but I think the 4-8 on the remote side may indicate a completely new message that the remote side is trying to send to Mirth, but that too is failing. Is there any configuration on Mirth's side that I could change to improve the stability? Would setting the Keep Connection Open under TCP Listener setting to FALSE help? 215, we also have a bunch of TCP Retransmission, for the second ack message it seems.ĭuring the second attempt, we see the two ADT messages get received and ACK sent back correctly. Is the remote side detecting that the packet is messed up and is requesting our side to send it again?
Then, I am not sure what TCP Retransmission (No.4 to 8) is trying to do. These packets get messed up (indicated by red line) and only one is received, and its Seq and Ack do not match - I'm not sure what this means. 1 to 9 are from one attempt, and 10 to 19 are from second attempt, about 5 minutes later.įrom the first attempt, we see that two ADT messages (top two green lines) are received on our side, and two ACK messages are sent. Looking at the remote side, packets from No. In this scenario, Remote Side is sending us an ADT message and we are responding back with ACK. Do they have the same TCP sequence numbers?Here is the comparison ( LINK): Try taking network captures on both the client side and the Mirth Connect side.
Mirth connect channel auto queue of errors professional#
PS: Is there a technical support personnel I can contact directly with Mirth? My company is willing to pay for professional support. Please let me know if you need any other information. If you could provide any insight, I would greatly appreciate it. I have also tested with HAPI on my local environment, with exactly the same message contents that failed previously, and was able to send in rapid succession with no packet loss. We initially thought it was an issue with the firewall, but we both have all ports open and some of our ACKs DO make it to our client. It seems to happen more often when the client sends us multiple (3~5) ADT messages in rapid succession (They have a DB poller on their side that gathers up all ADT messages and sends them out all at once).
This causes multiple re-transmission attempts from our side, to no avail.įrustratingly, this does not happen all the time - more like 3/10 times. Our tcpdump shows that Mirth indeed sends out the ACKs but client's side sees some of the ACKs and some others are broken (i.e., their received packet length does not match our sent packet length). Hence, the client's application treats the message as 'timed out' and puts it in an error queue and re-tries several times. ACK messages are being sent from Mirth correctly as well, however, only some make it to the client. Our client sends us ADT messages, and we are able to receive them. Response: Auto-generate (After source transformer) Source Queue: OFF (Respond after processing)
0 kommentar(er)
