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

[Daniel Fuchs]

On 24/05/2017 11:37, Michael McMahon wrote:
> 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?

Note sure what you're asking. I modified the test to make the
situation in which it failed the norm rather than the exception,
and I also modified the test to fix the race condition that
used to occur in this situation, so that the test no longer
(intermittently) fails.

best regards,

-- daniel

>
> 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