RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Chris Hegarty]

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