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

[Michael McMahon]

Hi Daniel,

Just so I understand correctly. The synchronization is needed
to guarantee that the error situation expected actually occurs,
where some data is left in this buffer on the client side
and it's not just dealing with some strange implementation detail of the 
test?

Michael

On 24/05/2017, 10:16, Daniel Fuchs wrote:
> [sent by mistake to core-libs-dev, sorry for cross posting]
>
> 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