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
