URLConnectionTest.testServerClosesOutput is flaky #4140
Comments
|
There are usually 2 requests sent to '/b' during the test: On successful runs, the server records #1 and then #2 and adds them to the queue in that order. On failed runs, the server starts reading request #1 before #2, but there is a context switch, and it finishes reading #2 before #1, recording them in that order. Since #1 is the last to be recorded, the test incorrectly uses it to assert that the sequence number is 0. Since #1 was the second to be received on the busted connection, it has a sequence number of 1 so the test fails. A simple fix is to assert that either #1 or #2 has a sequence number of 0. I wonder if there is a cleaner way to assert that a new connection was used. |
There are usually 2 requests sent to '/b' during the test: square#1 on the busted connection, attempting reuse square#2 on a new connection On successful runs, the server recorded square#1 and then square#2 and added them to the queue in that order. On failed runs, the server started reading request square#1 before square#2, but there was a context switch, and it finished reading square#2 before square#1, recording them in that order. Since square#1 was the last to be recorded, the test incorrectly used it to assert that the sequence number is 0. Since square#1 was the second to be received on the busted connection, it had a sequence number of 1 so the test failed. The fix removes the assumption that square#2 is the last to be recorded. Fixes square#4140.
There are usually 2 requests sent to '/b' during the test: square#1 on the busted connection, attempting reuse square#2 on a new connection On successful runs, the server recorded square#1 and then square#2 and added them to the queue in that order. On failed runs, the server started reading request square#1 before square#2, but there was a context switch, and it finished reading square#2 before square#1, recording them in that order. Since square#1 was the last to be recorded, the test incorrectly used it to assert that the sequence number was 0. Since square#1 was the second to be received on the busted connection, it had a sequence number of 1 so the test failed. The fix removes the assumption that square#2 is the last to be recorded. Fixes square#4140.
The text was updated successfully, but these errors were encountered: