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

[Michael McMahon]

The change looks fine to me Daniel

- Michael

On 24/05/2017, 11:41, Daniel Fuchs wrote:
> 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
>