8262027: Improve how HttpConnection detects a closed channel when taking/returning a connection to the pool #2649
Please find here a fix for:
While writing a new test to verify that it was possible to handle proxy and server authentication manually when both proxy and server required authentication, I stumbled on a race condition where the next request after receiving 407 would manage to retrieve the connection from the pool just before the connection close was receive from the proxy. Since the test was using POST, and POST are not retried by default, this caused the test to fail randomly and intermittently.
This fix proposes to add a checkOpen() method to HttpConnection, which we can call just after retrieving a connection from the pool. This method will attempt to read 1 byte from the channel. Because the connection was in the pool, it should not have received anything, and because the channel is non-blocking, the
This is not a 100% silver bullet, but it drastically reduced the number of failures I was observing (to 0 after several 100 loops of testing on all machines). The only other failures I observed was on windows, where apparently closing the socket on the server side can cause a reset, even when SO_LINGER and TCP_NODELAY are specified. I solved that by adding a small delay between socket.shutdownOutput() and socket.close() in the test proxy - when running on windows.
The text was updated successfully, but these errors were encountered:
@dfuch This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 10 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the
@dfuch Since your change was applied there have been 11 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit 0d2dbd2.