[
https://issues.apache.org/jira/browse/FLINK-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17328909#comment-17328909
]
Flink Jira Bot commented on FLINK-4423:
---------------------------------------
This major issue is unassigned and itself and all of its Sub-Tasks have not
been updated for 30 days. So, it has been labeled "stale-major". If this ticket
is indeed "major", please either assign yourself or give an update. Afterwards,
please remove the label. In 7 days the issue will be deprioritized.
> 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: Runtime / Coordination
> Reporter: Stephan Ewen
> Priority: Major
> Labels: stale-major
>
> 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
(v8.3.4#803005)
