RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

[Daniel Fuchs]

Hi Mark,

This is much simpler indeed.
Thumbs up from me :-)

best regards,

-- daniel

On 12/2/13 1:35 PM, Mark Sheppard wrote:
> Hi
>     based on feedback the changes for issue:
> https://bugs.openjdk.java.net/browse/JDK-8025211
>
> have been amended to the following:
> http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/
>
> please oblige and review
>
> regards
> Mark
>
> On 29/11/2013 17:17, Mark Sheppard wrote:
>>
>> Alan, Daniel,
>>    thanks for the replies.
>>
>> yes, 'tis a possibility, and it appears to work ok as a test, as it
>> avoids the sender's Thread.sleep creating a race condition, such that
>> the send doesn't happen prior to the timeout of the client receive.
>>
>> The context of the test appears to be creating conditions
>> such that an ICMP  PortUnreachable event is generated,
>> which caused a close a particular version of windows.
>> The test is for socket closed scenario, afaik
>>
>> tested on the errant test machine with consistent success.
>>
>> regards
>> Mark
>>
>> On 29/11/2013 16:41, Daniel Fuchs wrote:
>>> On 11/29/13 5:19 PM, Alan Bateman wrote:
>>>> On 29/11/2013 14:21, Mark Sheppard wrote:
>>>>> Hi
>>>>> please oblige and review the following changes
>>>>>
>>>>> http://cr.openjdk.java.net/~msheppar/8025211/webrev/
>>>>> which address the issue raised in the bug
>>>>> https://bugs.openjdk.java.net/browse/JDK-8025211
>>>>>
>>>>> an intermittent failure occurs on some windows test machines.
>>>>>
>>>>> this replaces a Thread.sleep(5000) with explicit synchronization
>>>>> between sender
>>>>> and receiver via a CountDownLatch
>>>> (cc'ing net-dev)
>>>>
>>>> Would an alternative here be to just get rid of the server thread (do
>>>> both the send + receive on the main thread)?
>>>
>>> Hmm... The message sent by the server is short enough so that it
>>> should be stored in the client's socket buffer and received later
>>> by the client, even though the client is not yet blocked waiting
>>> in clientSock.receive() when the message is sent.
>>>
>>> That might work.
>>>
>>> Unless multi-threading was relevant to the configuration being
>>> tested?
>>>
>>>
>>> -- daniel
>>>
>>>>
>>>> -Alan
>>>
>>
>