You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2021/05/25 00:06:00 UTC

[jira] [Updated] (HBASE-25911) Fix uses of System.currentTimeMillis (should be EnvironmentEdgeManager.currentTime)

     [ https://issues.apache.org/jira/browse/HBASE-25911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Kyle Purtell updated HBASE-25911:
----------------------------------------
    Summary: Fix uses of System.currentTimeMillis (should be EnvironmentEdgeManager.currentTime)  (was: Replace uses of System.currentTimeMillis with EnvironmentEdgeManager.currentTime)

> Fix uses of System.currentTimeMillis (should be EnvironmentEdgeManager.currentTime)
> -----------------------------------------------------------------------------------
>
>                 Key: HBASE-25911
>                 URL: https://issues.apache.org/jira/browse/HBASE-25911
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Kyle Purtell
>            Assignee: Andrew Kyle Purtell
>            Priority: Minor
>             Fix For: 3.0.0-alpha-1, 2.5.0
>
>
> We introduced EnvironmentEdgeManager a long time ago as a way to inject alternate clocks (gettimeofday() aka System.currentTimeMillis()) for unit tests. In order for this to be effective, all callers that would otherwise use System.currentTimeMillis() must call EnvironmentEdgeManager.currentTime() instead, except obviously the implementors of EnvironmentEdge.
> It's common for contributors to be unaware of this practice and reviewers might not catch it.
> It will be much more important to have EnvironmentEdgeManager in use where expected once we have EnvironmentEdge also providing a monotonic clock source. (See parent.)
> On another subtask I will introduce a build enforcer that bans System.currentTimeMillis() except where annotated to allow it.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)