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

[Mark Sheppard]

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
>