Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Timeout waiting for ACK" reported even when it's actually a SocketException #1077

Closed
rbeckman-nextgen opened this issue May 11, 2020 · 4 comments
Milestone

Comments

@rbeckman-nextgen
Copy link
Collaborator

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Look at MllpMessageDispatcher.java and TcpMessageDispatcher.java. They each have their own getAck(), which in both cases of timeout or other exception, returns null. Back in the methods that called getAck(), null is interpreted to mean timeout (for LLP) or "Empty Response" (TCP), and this is recorded in the message history.

This is very misleading when troubleshooting network problems. Please put the reason for the exception in case there was one besides timeout, like "Connection reset by peer", etc.

Imported Issue. Original Details:
Jira Issue Key: MIRTH-1073
Reporter: steven_kehlet
Created: 2009-04-17T13:18:19.000-0700

@rbeckman-nextgen rbeckman-nextgen added this to the 3.0.0 Beta 1 milestone May 11, 2020
@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Figured out how to fix the problem for the LLP Sender, but it might cause more problems with the listener, since it ends up in LlpProtocol.java. readLLP() should throw appropriate exceptions instead of returning null. getAck() in MllpMessageDispatcher.java should do the same.

Imported Comment. Original Details:
Author: jacobb
Created: 2009-05-18T17:28:18.000-0700

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

This is resolved as of revision 5977. The TCP connectors now only report a timeout (through logging/alerts) if an actual SocketTimeoutException has occurred. On the receiver side, if the connection is being kept open and a timeout occurs, it doesn't trigger a logger.error or alert, but still triggers a logger.debug and sends an INFO event to the MonitoringController. On the dispatcher side, the socket's input stream is only read from if the response isn't being ignored, so all IOException occurrences trigger the logger/alerts/monitor. The error message reported is changed to "Timeout waiitng for response" if the exception is a SocketTimeoutException however.

Imported Comment. Original Details:
Author: narupley
Created: 2012-11-30T11:20:32.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

To test this one, use a TCP Sender to send to a non-listening port and verify that a connection refusal exception is thrown rather than a timeout exception.

To test the other fringe case, you would have to have a receiver manually close it's socket AFTER the sender started attempting to read from the socket, and BEFORE the sender was able to succesfully read the entire response.

Here's a sample unit test for the latter case:

@test
public final void testTcpTimeoutException() throws Exception {
StateAwareServerSocket serverSocket = new StateAwareServerSocket(9001, 256);
StateAwareSocket socket = serverSocket.accept();
socket.setReceiveBufferSize(65536);
socket.setSendBufferSize(65536);
socket.setSoTimeout(10000);
socket.setKeepAlive(true);
socket.setReuseAddress(true);
socket.setTcpNoDelay(true);
// Read at least one byte
assertFalse(socket.getInputStream().read() == -1);
// Close the socket manually before the response is sent
SocketUtil.closeSocket(socket);
}

Imported Comment. Original Details:
Author: narupley
Created: 2012-12-20T19:56:49.000-0800

@rbeckman-nextgen
Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Confirmed that sending to a unbound socket results in a refusal exception (also in the server log and connector log).

Also confirmed that if you prop up a receiver that manually closes the connection before the TCP Sender has a chance to read from the socket, a timeout exception is not thrown; instead no response bytes are captured, and a "No response was received" message is sent as the ERROR response data.

Imported Comment. Original Details:
Author: narupley
Created: 2012-12-21T12:17:36.000-0800

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.