-
Bug
-
Resolution: Fixed
-
P4
-
7, 8
-
b29
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8084960 | emb-9 | Peter Levart | P4 | Resolved | Fixed | team |
| JDK-8292980 | openjdk8u352 | Peter Levart | P4 | Resolved | Fixed | b05 |
This CR is filed to replace currentTimeMillis with nanoTime in InetAddress$Cache, reasons are below:
1. It has been confirmed that on certain Vitrual Machines the wall clock time (System.currentTimeMillis) is not advancing by the exected sleep() time. This plays havoc with the internal negative lookup cache mechanism in InetAddress ( which uses currentTimeMillis ). If the negative cache is set for 15 seconds, sleeping for 16 seconds will not guarantee that the cache will be invalidated! see CR7148829
2. Compared with currentTimeMillis, the nanoTime is only be used to measure elapsed time and not related to any other notion of system or wall-clock time.
1. It has been confirmed that on certain Vitrual Machines the wall clock time (System.currentTimeMillis) is not advancing by the exected sleep() time. This plays havoc with the internal negative lookup cache mechanism in InetAddress ( which uses currentTimeMillis ). If the negative cache is set for 15 seconds, sleeping for 16 seconds will not guarantee that the cache will be invalidated! see CR7148829
2. Compared with currentTimeMillis, the nanoTime is only be used to measure elapsed time and not related to any other notion of system or wall-clock time.
- backported by
-
JDK-8084960 InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8331184 Make the time source used for the InetAddress DNS cache configurable
-
- Open
-
-
-
- Resolved
-
(2 links to)