A message is received in an HTTP Sender destination, and held there for about 3 minutes

[Coooz]

Hi,

Referring to the below image...

"to MososNXT" is a HTTP Sender destination, and as you can see it always takes about three minutes before the status is set from RECEIVED to SENT and the Response Date is set. This destination earlier on gave errors like "Error connecting to HTTP server - java.net.SocketTimeoutException: Read timed out" and "Error connecting to HTTP server -
org.apache.http.NoHttpResponseException: localhost:19101 failed to respond". Since then I queue messages "On Failure" with 2 retries and an interval of 10000 ms and at least the errors are gone - but the three minute delay is very annoying.

Each time I click the Test Connection button in the destination, the connection is always immediately succesful. Also the file writer destination that I added for testing works without problems.

So, how can I get rid of this three minute delay or at least decrease the amount of time to something acceptable? I'm using Mirth Connect 4.4.2.

Thanks in advance!

[pacmano1]

How big is the file you are sending? How fast is their connection to accept the post?

If the files are very small, are you doing something else in your channel like writing a log row?

"Test connection" effectively just tests a port, so not a measure of throughput.

[jonbartels]

Right click on the header row in the message view and add the other time-based columns. There should be a "send date".

If the "received date" and "send date" are ~3 minutes, then its your code that is slow.
If the "received date" and "send date" are close then it is the actual transmission of the message that is slow.

There can be some exceptions (like response processing) but rule out the simple stuff first.

https://docs.nextgen.com/bundle/Mirth_User_Guide_411/page/connect/connect/topics/c_Message_Metadata_connect_ug.html

[Coooz]

The channel that had the 3 minute delay received its messages from another channel, and somehow I solved the issue by combining both into one. Not quite sure what caused the issue though, but the overall solution is simpler now and works as intended.
Thank you @jonbartels and @pacmano1 for contributing.