You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Andrey Zagrebin (JIRA)" <ji...@apache.org> on 2018/11/08 14:13:00 UTC

[jira] [Created] (FLINK-10830) Consider making processing time provider pluggable

Andrey Zagrebin created FLINK-10830:
---------------------------------------

             Summary: Consider making processing time provider pluggable
                 Key: FLINK-10830
                 URL: https://issues.apache.org/jira/browse/FLINK-10830
             Project: Flink
          Issue Type: Improvement
            Reporter: Andrey Zagrebin


At the moment, the processing time is basically implemented in a fixed way as 

System.currentTimeMillis() and not configurable by users.

If this implementation does not fit application business logic for some reason there is no way for users to change it.

Examples:
 * The timestamp provided by currentTimeMillis is not guaranteed to be monotonically increasing. It can jump back for a while because of possible periodic synchronisation of local clock with other more accurate system. It can be a problem for application business logic if we say that the general notion of time is that it always increases.
 * Hard to implement end-to-end tests because synchronisation between time in test and in Flink is out of control.

We can make it configurable and let users optionally set their own factory to create processing time provider. All features which depend on querying current processing time can use this implementation. The default one can still stay System.currentTimeMillis().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)