RFR: 8281511: java/net/ipv6tests/UdpTest.java fails with checkTime failed [v4]

Mark Sheppard msheppar at openjdk.org
Fri Feb 28 14:50:52 UTC 2025


On Fri, 28 Feb 2025 14:40:28 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> switching to nanoTime as suggested in ticket comments
>
> serhiysachkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281511: update Copyright header

I think the checkTime from the base class Tests, should be reviewed in the context of the reported failures, where some of the actual timeouts registered are 10699 , 16926, 17926

The timeout check is

   /* check the time got is within 50% of the time expected */
    public static void checkTime (long got, long expected) {
        checkTime(got, expected, expected);
    }

    /* check the time got is between start and end, given 50% tolerance */
    public static void checkTime(long got, long start, long end) {
        dprintln("checkTime: got = " + got + " start = " + start + " end = " + end);
        long upper = end + (end / 2);
        long lower = start - (start / 2);
        if (got > upper || got < lower) {
            throw new RuntimeException("checkTime failed: got " + got
                    + ", expected between " + start + " and " + end);
        }
    }

which uses arbitrary upper bounds and lower bounds.

If a timeout is set at 5000 milliseconds then the expectation is that, should the timeout expire and a SocketTimeoutException is thrown, then the actual elapsed time will be equal to, or greater than, the specified timeout value passed to setSoTimeout. The minimum timeout is 5000 milliseconds, that is the lower bound for any timeout expiry check. Any earlier return would indicate a spurious wakeup by the OS.

In the checkTime a lower bound of less than the expected timeout is tolerated, and then an upper bound of an additional 50% is utilised as a check. Looking at the reported failures scenarios the actual elapsed time is significantly greater than the (timeout + 50%) value.

It is proffered that in reality no upper bound, other than > timeout value should be imposed on the timeout check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23840#issuecomment-2690829007


More information about the net-dev mailing list