JDK-8281511 : java/net/ipv6tests/UdpTest.java fails with checkTime failed
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 17,18,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2022-02-08
  • Updated: 2025-04-08
  • Resolved: 2025-03-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 21 JDK 24 JDK 25
17.0.16-oracleFixed 21.0.8-oracleFixed 24.0.2Fixed 25 b13Fixed
Related Reports
Relates :  
Relates :  
Description
the test2 scenario fails due to the calculated timeout of a receive being greater than the imposed quasi realtime upper bound.

Test2 starting
checkTime: got = 10699 start = 4000 end = 4000
----------System.err:(13/669)----------
java.lang.RuntimeException: checkTime failed: got 10699, expected between 4000 and 4000
	at Tests.checkTime(Tests.java:164)
	at Tests.checkTime(Tests.java:155)
	at UdpTest.test2(UdpTest.java:147)
	at UdpTest.main(UdpTest.java:88)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:833)
Comments
Fix request [17u] I backport this for parity with 17.0.16-oracle. No risk, only a test change. Resolved Copyright, clean anyways. Test passes.SAP nightly testing passed.
07-04-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3448 Date: 2025-04-06 11:13:24 +0000
06-04-2025

[jdk21u-fix-request] Approval Request from sendaoYan Clean backport to fix the test bug which cause test intermittent fails. Change has been verified locally, test-fix only, no risk.
13-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1475 Date: 2025-03-12 01:25:47 +0000
12-03-2025

[jdk24u-fix-request] Approval Request from sendaoYan Clean backport to fix the test bug which cause test intermittent fails. Change has been verified locally, test-fix only, no risk.
09-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk24u/pull/121 Date: 2025-03-08 14:19:21 +0000
08-03-2025

Changeset: ea9e3cfe Branch: master Author: Serhiy Sachkov <serhiy.sachkov@oracle.com> Committer: Mark Sheppard <msheppar@openjdk.org> Date: 2025-03-05 16:16:58 +0000 URL: https://git.openjdk.org/jdk/commit/ea9e3cfe03b5284ef0edc6f0eb92fcb6ffd62725
05-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23840 Date: 2025-02-28 10:38:19 +0000
28-02-2025

These tests use System.currentTimeMillis() so contemporary thinking is to use nanoTime Additionally the checkTime is suspect to OS scheduling delays and will result in intermittent failures. Whether to retain the current epoch calculation using 50% or to double the epoch can be a topic of debate
18-02-2025

Some adjustment of the checkTime is needed for this test to avoid intermittent timeCheck failures. The simple fact that the timeout has occurred should be sufficient to pass the test. Nonetheless it raises some questions on the exactness and precision of the timeout expiry, especially on heavily loaded systems
09-02-2022