[
https://issues.apache.org/jira/browse/OOZIE-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465041#comment-13465041
]
Robert Kanter commented on OOZIE-994:
-------------------------------------
The reason I used a set of ErrorInfos was from the javadoc of registerError():
{{@param exClass excpetion class name (to work in case of a particular
exception not being in the classpath, needed to be able to handle multiple
version of Hadoop or other JARs used by executors with the same codebase).}}
I'm not entirely sure, but it seems to imply that you could have multiple
versions of the same exception class (e.g. multiple implementations of the same
exception class). Because I changed the key of the ERROR_INFOS to be the name
of the exceptions (i.e. org.blah.blah.WhateverException), two implementations
of the same exception class would have the same name. Is that not what the
javadoc is saying?
I didn't think about subclasses not being handled when I made my changes.
Thinking about this now it seems tricky because:
1) If only the superclass is registered, we should catch subclasses as that
superclass
2) If both the superclass and subclass are registered, we should catch them
separately
I think this was working before because, as you pointed out earlier, the
exceptions are registered in the "correct" order when it was just checking
{{isInstance()}}; I suppose we can keep this approach, but it doesn't seem
ideal.
> 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,
> 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
