On 17/01/2014 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.
Looking at JDK-8031666 then the failure seems to be with the r
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(DualStackPlainDatagramS
Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/
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
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 s
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/2
On 17/01/14 10:48, 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/
Oh, we should really increase the acceptable expected time in the
subsequent checkTime call. From say 2000 -> 4000.
On 17/01/2014 10:39, Tristan Yan wrote:
Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/
Thank you
Tristan
This looks okay but I just wonder if we also need to adjust the
tolerance in checkTime. As I read it then it checks allows for +/- 50%,
w
Shall we adjust runAfter time a little bigger also if you're doing this.
Because if network is fast enough. All thing could be finished less than
3000 ms
Thank you
Tristan
On 01/17/2014 07:20 PM, Chris Hegarty wrote:
Oh, we should really increase the acceptable expected time in the
subsequent
On 17/01/14 11:24, Tristan Yan wrote:
Shall we adjust runAfter time a little bigger also if you're doing this.
Because if network is fast enough. All thing could be finished less than
3000 ms
No, this is just a wait/delay time before sending the packet. A simple
update to the expected time, 2
On 17/01/2014 11:45, Chris Hegarty wrote:
On 17/01/14 11:24, Tristan Yan wrote:
Shall we adjust runAfter time a little bigger also if you're doing this.
Because if network is fast enough. All thing could be finished less than
3000 ms
No, this is just a wait/delay time before sending the packe
Sorry, you're right. Change to 4000 means tolerance will be 2000ms to
6000ms. And timeout will be 6000ms.
Thank you for sponsor this.
Tristan
On 01/17/2014 07:45 PM, Chris Hegarty wrote:
On 17/01/14 11:24, Tristan Yan wrote:
Shall we adjust runAfter time a little bigger also if you're doing
11 matches
Mail list logo
