[
https://issues.apache.org/jira/browse/APEXCORE-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187404#comment-16187404
]
ASF GitHub Bot commented on APEXCORE-619:
-----------------------------------------
vrozov closed pull request #490: APEXCORE-619 Checkpoint leaf stateless
operator for correct recovery after application restart.
URL: https://github.com/apache/apex-core/pull/490
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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.4.14#64029)
