A connection used by a gateway may timeout prematurely.
Previously, the socket read timeout simply controlled when
a socket would be closed after the timeout occurred.
Consider a connection with so-timeout set to 10 seconds; the
application initializes at T+0 and the first message is sent,
with the server responding immediately; the timeout clock starts.
Next, a message is sent at T+5 to a service that takes 6 seconds
to respond. The connection will timeout at T+10 before the
response is received; the socket is closed and client does not
receive the response.
The solution is to wait 2 timeout cycles *IF* a message has
been sent within the current timeout.
Maintain a timer for the last send() operation. When a socket
timeout occurs, examine the last sent time; if within the
timeout, defer the close until the next timeout.
We cannot simply rely on the last send time because, when
using collaborating adapters, continuous sends (with no replies)
would defer the close indefinitely. Hence, the second test looking
to see if we have not had a successful read for the last 2 timeouts.
NIO does not directly support socket timeouts (because there is no
thread hanging on the read); instead, the timeout logic is
performed on the selector thread.
Rename DefaultTimeoutTests to ConnectionTimeoutTests.
Add tests (for both Socket and NIO connections) to assert the correct
operation when a send is performed within a timeout, as well as
when the server takes > 2x the timeout to respond.
INT-2860 Fix Typo in Exception Message
Error sending meeeage.
removed invalid comment from test (while merging)
e4722de464