[
https://issues.apache.org/jira/browse/OOZIE-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577281#comment-13577281
]
Virag Kothari commented on OOZIE-1205:
--------------------------------------
{quote}second action to get marked as FAILED because its hadoop job also failed
{quote}
I see the new FailX command also marking the second action as KILLED
{quote} FAILED is technically more correct {quote}
If the first action fails, then the workflow should be killed immediately and
the second action should also be marked KILLED if it is in non-terminal state.
I don't think the second action should be allowed to wait to reach the FAILED
state (even if it is eventually going to reach the FAILED state due to hadoop
job failure).
{quote} Do you mean we should do something (what?){quote}
I meant RecoveryService for handling commands that are lost.
> If the JobTracker is restarted during a Fork, Oozie doesn't fail all of the
> currently running actions
> -----------------------------------------------------------------------------------------------------
>
> Key: OOZIE-1205
> URL: https://issues.apache.org/jira/browse/OOZIE-1205
> Project: Oozie
> Issue Type: Bug
> Components: action
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk, 3.3.2
>
> Attachments: OOZIE-1205.patch
>
>
> If you have a workflow with a fork and restart the JobTracker while its
> executing the paths in the fork, those two jobs will be lost (as expected).
> Once the timeout occurs on the {{ActionCheckXCommand}}, it will check both
> actions sequentially. While checking the first action, it sets the status to
> FAILED and also sets the workflow's status to FAILED. It then moves on to
> the other action that was running concurrently, but it cannot pass the
> precondition check because the workflow was already FAILED (the check
> requires that the Workflow is RUNNING). It will keep trying this every time
> the timeout hits (10min is default) and print a WARN message in the log.
> That action will also be in RUNNING state forever even though the underlying
> job isn't running and the WF is FAILED.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
