You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by "Vlad Rozov (JIRA)" <ji...@apache.org> on 2017/02/12 21:58:41 UTC

[jira] [Updated] (APEXCORE-619) recovery window id in future for terminating state less operators during relaunch.

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

Vlad Rozov updated APEXCORE-619:
--------------------------------
    Priority: Minor  (was: Major)

> recovery window id in future for terminating state less operators during relaunch.
> ----------------------------------------------------------------------------------
>
>                 Key: APEXCORE-619
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-619
>             Project: Apache Apex Core
>          Issue Type: Bug
>            Reporter: Tushar Gosavi
>            Assignee: Tushar Gosavi
>            Priority: Minor
>
> With following DAG
> A -> B -> C
> C is a stateless operator. If this application is killed and restarted after long time between kill and restart, then recovery window id of C is too high compare to A and B. This is because recovery windowid is computed from current timestamp for stateless operators in updateRecoveryCheckpoints.
> The problem this causes 
> - Operator C does not process any data till windowId of B reached to recovery window id of C.
> - If other operators are not able to keep up then C gets killed because it is detected as blocked operator.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)