The bug shows the following stacktrace:
----------System.err:(16/903)----------
java.net.SocketTimeoutException: Receive timed out
at
java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native
Method)
at
java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109)
at java.net.DatagramSocket.receive(DatagramSocket.java:721)
at UdpTest.test2(UdpTest.java:159)
at UdpTest.main(UdpTest.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746)
at java.lang.Thread.run(Thread.java:744)
----
So the failure was not related to the initial two receives that are
expected to timeout. 4000 millis should be sufficient for these.
The failure looks like it is because the third receive, that is expected
to NOT timeout, does timeout. The socket timeout value is still set, in
the original code, to 4000 millis. It should be more efficient to simply
increase the timeout of the socket just before the third received, to
say 10000 millis.
Make sense?
-Chris.
On 17/01/14 05:40, Tristan Yan wrote:
Hi All
Please review the simple code fix for JDK-8031666.
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/
This test fails in very small chance. Adding socket timeout a little bigger.
Thank you
Tristan
