[
https://issues.apache.org/jira/browse/HDDS-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932724#comment-17932724
]
Steve Loughran commented on HDDS-12459:
---------------------------------------
we do have to handle the issue that when a thread is suspended on one core and
resumed elsewhere, the core-local or socket-local clock maybe different
some Intel cpu versions had different clocks per core; later releases have all
cores in sync, but you still don't have consistency over sockets. that is: if a
thread is rescheduled on a different socket within a multisocket system, the
clock will be wrong.
I don't think this is reason to give up, just that maybe rather than just
exposing clock, a duration tracker can be exposed which knows that when it sees
time going backwards it sets current time to start time.
I use {{org.apache.hadoop.util.OperationDuration}} for counting some things,
with {{DurationTracker}} for statistics.
This works but is inefficient. If we could do that duration tracking using
nanotime and handle time going backwards (which these classes don't) then we'd
have a lower cost counter for statistics and retry logic where a bit of
inaccuracy is fine
> System clock should not be used for measuring time duration
> -----------------------------------------------------------
>
> Key: HDDS-12459
> URL: https://issues.apache.org/jira/browse/HDDS-12459
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Tsz-wo Sze
> Assignee: Chia-Chuan Yu
> Priority: Major
>
> java.time.Clock (system(ZoneId) / systemDefaultZone() / systemUTC()) uses
> System.currentTimeMillis(). As described in HADOOP-15901, this could result
> in undesired results when system clock's time changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
