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

Mark Sheppard mark.sheppard at oracle.com
Mon Dec 2 12:35:14 UTC 2013


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




More information about the core-libs-dev mailing list