[jira] [Commented] (FLINK-4423) Introduce a Clock utility for monotonous system timestamps

["mingleizhang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095743#comment-16095743 ] 

mingleizhang commented on FLINK-4423:
-------------------------------------

[~StephanEwen] This is a very interesting topic indeed . One question I would like to ask and confirm, We add Clock utility is that because we want to repair or fixing the existence of the {{System.currentTimeMillis()}} which is not monotonous issue ? With remembers the max returned timestamp and that will let the new function has the same functionality as {{System.nanoTime()}}. I understand correct ?

> Introduce a Clock utility for monotonous system timestamps
> ----------------------------------------------------------
>
>                 Key: FLINK-4423
>                 URL: https://issues.apache.org/jira/browse/FLINK-4423
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Stephan Ewen
>
> I suggest to introduce a {{Clock}} class that provides a {{currentTimeMillis()}} function that calls {{System.currentTimeMillis()}} but also remembers the max returned timestamp so far. That way it would never return decreasing timestamps.
> In the presence of clock backwards adjustments, the appearance would be that time stands still for a while, until the clock has caught up with the previous timestamp.
> Since we don't rely on this for measuring timeouts, but only for logging / visualization / etc (see [FLINK-4422])  it should not mess up any distributed system behavior.
> We would use this in places like the {{ExecutionGraph}}, where we record timestamps for state transitions. That way, the utilities that derive charts and times from the status timestamps would not be thrown off if timestamps were decreasing when expected increasing.
> The same holds for ingestion time timestamps and for processing time triggers.
> NOTE: I would like some other opinions on that - it is a somewhat delicate matter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)