-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Inconsistency in pooled-but-unused TCP connection error between Windows and Linux/MacOs #5108
Comments
thanks I am not sure this is achievable unless as you said you set an exception handler on the connection. The pool itself does not interact with the connection exception handler, since the connection exists outside of the pool and one could set an exception handler on it and the pool would overwrite it. as a facility, you can set a connect handler on the HttpClientBuilder that would facilitate the setup of such strategy instead of melting that in your request/response code |
Thanks for looking at this, but can't we update the connection's |
thing is that a connection can be partially in the pool like HTTP/2 |
I saw that HTTP/1.1 and HTTP/2 connections both have a notion of active stream, so I guess we could hook something here and update the connection exception handler as soon as this active stream count reaches 0. |
Version
I use Vert.x 4.5.2
Context
This is the timeline:
Then:
I think that this error should be hidden as the connection is not used when the exception happen. So this could be logged at
debug
ortrace
level instead. Moreover, when multiple connections are open to the same HTTP Server, then this message appears multiple times.This is a broader issue than just a Windows compatibility one (see "Investigation" below), as it would end up the same on MacOs/Linux in case of any failure of a pooled-but-unused connection.
Workaround
Fortunately, there is a workaround: one can set a connection exception handler before sending the request, then the exception will be sent to the connection error handler and not be treated as uncaught.
Do you have a reproducer?
Yes, although this seems to happen only when the process itself is killed. I've tried otherwise but didn't succeed in failing the connection on client side. Although I guess this could be done using Mock in Vert.x test.
Server code:
Client code:
Investigation
I've run this reproducer on MacOs and No exception at all is thrown when the server process is killed. This is why no exception is logged on Linux/MacOs. But if we achieved to have this
java.net.SocketException
thrown byjava.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
(or any other socket exception) then Vert.x behavior would be the same.The text was updated successfully, but these errors were encountered: