EOFException when using NIO feature of TcpConnection socket client [INT-4525] #8463
Comments
|
Gary Russell commented It is true that we can get notified of the close asynchronously, and we can get it before the data. We have the following code to protect against that condition: boolean waitForMessageAfterError = true;
while (this.reply instanceof ErrorMessage) {
if (waitForMessageAfterError) {
/*
* Possible race condition with NIO; we might have received the close
* before the reply, on a different thread.
*/
logger.debug("second chance");
this.secondChanceLatch.await(2, TimeUnit.SECONDS); // NOSONAR don't care about result
waitForMessageAfterError = false;
}
else if (this.reply.getPayload() instanceof MessagingException) {
throw (MessagingException) this.reply.getPayload();
}
else {
throw new MessagingException("Exception while awaiting reply", (Throwable) this.reply.getPayload());
}
}But it appears that 2 seconds is sometimes not enough in your environment, so we should make it configurable. That said, it sounds like the added complexity of NIO is not really required since your sockets are short-lived. NIO is really beneficial when you have many open long-lived sockets. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
member sound opened INT-4525 and commented
If I use nio
tcpConnectionFactoryFactoryBean.setUsingNio(true), I'm getting lots ofEOFExceptionswhile waiting on socket replies.As soon as I switch to
false, the eof exceptions are gone.One important thing: the server I connect to always directly closes the connection right after sending the reply. Maybe spring sometimes did not read the full socket reply when catching the "socket close", and fails thereafter?
It's hard to reproduce, as the EOF only occurs occasionally. But it is clearly related to the nio feature, as it never occurs if nio is false!
Some logs:
Affects: 5.0.7
Referenced from: pull request #2558
The text was updated successfully, but these errors were encountered: