Thank you
Tristan
On 01/17/2014 06:48 PM, Chris Hegarty wrote:
On 17/01/14 10:39, Tristan Yan wrote:
Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/
Thanks, approved. I can sponsor this change for you.
-Chris.
Thank you
Tristan
On 01/17/2014 06:32 PM, Chris Hegarty wrote:
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
