You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Robert Metzger (JIRA)" <ji...@apache.org> on 2019/02/28 15:48:00 UTC

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

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

Robert Metzger updated FLINK-10830:
-----------------------------------
    Component/s: Runtime / Operators

> Consider making processing time provider pluggable
> --------------------------------------------------
>
>                 Key: FLINK-10830
>                 URL: https://issues.apache.org/jira/browse/FLINK-10830
>             Project: Flink
>          Issue Type: Improvement
>          Components: Runtime / Operators
>            Reporter: Andrey Zagrebin
>            Priority: Major
>
> 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)