Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Date: Fri, 21 Oct 2016 09:13:59 +0000 (UTC)
From: "Maximilian Michels (JIRA)" <jira@apache.org>
To: issues@flink.apache.org
Message-ID: <JIRA.13006433.1474446724000.50057.1477041239089@Atlassian.JIRA>
In-Reply-To: <JIRA.13006433.1474446724000@Atlassian.JIRA>
References: <JIRA.13006433.1474446724000@Atlassian.JIRA> <JIRA.13006433.1474446724281@arcas>
Subject: [jira] [Updated] (FLINK-4651) Re-register processing time timers at
 the WindowOperator upon recovery.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 21 Oct 2016 09:14:01 -0000


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

Maximilian Michels updated FLINK-4651:
--------------------------------------
    Fix Version/s:     (was: 1.1.3)
                   1.1.4

> Re-register processing time timers at the WindowOperator upon recovery.
> -----------------------------------------------------------------------
>
>                 Key: FLINK-4651
>                 URL: https://issues.apache.org/jira/browse/FLINK-4651
>             Project: Flink
>          Issue Type: Bug
>          Components: Windowing Operators
>            Reporter: Kostas Kloudas
>            Assignee: Kostas Kloudas
>              Labels: windows
>             Fix For: 1.2.0, 1.1.4
>
>
> Currently the {{WindowOperator}} checkpoints the processing time timers, but upon recovery it does not re-registers them with the {{TimeServiceProvider}}. To actually reprocess them it relies on another element that will come and register a new timer for a future point in time. Although this is a realistic assumption in long running jobs, we can remove this assumption by re-registering the restored timers with the {{TimeServiceProvider}} in the {{open()}} method of the {{WindowOperator}}.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)