[
https://issues.apache.org/jira/browse/OOZIE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462275#comment-13462275
]
Virag Kothari commented on OOZIE-994:
-------------------------------------
As a LinkedHashMap is used to store the registeredExceptions and as an
entrySet() is being used to iterate over the exceptions, the ordering of the
exceptions will be preserved. Also, I see that exceptions like IOException are
registered in the end. (In JavaActionExecutor).
So we can avoid this subclass match problem by checking whether the exception
is set or not. If its set, it should not be set again.
So just making this change in the code from above would work:
{code}
Exception e = null;
if (match (Exception)){
if (e==null){
e = new AEException ("..")
}
}
}
{code}
> ActionCheckXCommand does not handle failures properly
> -----------------------------------------------------
>
> Key: OOZIE-994
> URL: https://issues.apache.org/jira/browse/OOZIE-994
> Project: Oozie
> Issue Type: Bug
> Components: workflow
> Affects Versions: 3.2.0
> Reporter: Alejandro Abdelnur
> Assignee: Robert Kanter
> Priority: Critical
> Fix For: trunk
>
> Attachments: OOZIE-994.patch, OOZIE-994.patch, OOZIE-994.patch
>
>
> If the JT restarts or dies and running jobs are lost or the JT is not
> reachable, Oozie ActionCheckXCommand will never fail the workflow job.
> There seem to be 2 issues here:
> * convertException is not receiving the root cause exception anytmore, but
> alway HadoopAccessorException wrapping the root cause exception. We should
> modify the convertException to inspect the cause exception as well.
> * ActionCheckXCommand does not do the handle retry logic of
> ActionStartXCommand.
--
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
