9 (test only) RFR: 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout

Pavel Rappo pavel.rappo at oracle.com
Thu May 25 07:53:17 UTC 2017


Daniel, thanks for taking care of this! Looks good.

> On 24 May 2017, at 12:14, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a test-only fix for:
> 
> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
> https://bugs.openjdk.java.net/browse/JDK-8180279
> 
> The failing testcase is RawChannelTest.
> 
> The test appears to be failing because of a flaw in the test logic which
> allowed for a race condition between the client and the (fake) server.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
> 
> What can be seen from the traces is that when the test fails,
> the client is writing bytes to the server and the server is
> writing bytes to the client but the client never wakes up to read
> the bytes. It can also be seen that the client has found some bytes
> in the 'initialByteBuffer' of the RawChannel.
> 
> What happens here is that the initialRawBuffer has read all
> the bytes that were available in the channel - and the server
> is waiting for the client to stall before writing more bytes.
> But the code that will unblock the server is never executed,
> because it is triggered by a selector read event, and the
> channel is already dry so the event is never fired.
> 
> I reworked the tests a bit, adding two new CountDownLatches to
> ensure that 1. the client will always find initial bytes in the
> channel's initialByteBuffer (the intermittent condition that made
> the test fail) and 2. the server will wait for the client to
> signal that it has got the initial bytes, and write an additional
> chunk of bytes that will trigger the selector read (which will
> in turn ensure that the client will unblock the server later on).
> 
> best regards,
> 
> -- daniel



More information about the core-libs-dev mailing list