flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan Ewen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FLINK-4423) Introduce a Clock utility for monotonous system timestamps
Date Thu, 18 Aug 2016 11:01:20 GMT
Stephan Ewen created FLINK-4423:

             Summary: 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
            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

View raw message