ErrorType.NON_TRANSIENT is not handled when an ActionExecutorException is thrown from check().
See the catch block of ActionCheckXCommand.execute(), note that the switch on ErrorType only has cases for FAILED, ERROR, and TRANSIENT. This exists in the 3.3.2 and trunk: http://svn.apache.org/viewvc/oozie/trunk/core/src/main/java/org/apache/oozie/command/wf/ActionCheckXCommand.java?view=markup On Wed, Jun 12, 2013 at 1:54 PM, Mona Chitnis <[email protected]> wrote: > > > On 6/11/13 7:20 PM, "Alexander Taggart" <[email protected]> wrote: > > >1. As far as I understand, you have two choices: (1) a synchronous action > >that blocks in start() until the work is done, and then invokes > >context.setExecutionData(); (2) an asynchronous action obtains a URL from > >context.getCallbackUrl(), then somehow getting your work unit to make a > >GET > >to that URL when the work is done, which I think results in > >action.isCompleted() being invoked with the external status value attached > >to the URL as a query param. > > > >2. I think you either need to throw an ActionExecutorException explicitly, > >or register your exceptions via action.registerError. If you use > >ErrorType.TRANSIENT (either in the exception or the registration), then > >oozie will go through its retry process. > > > >Note that (at least in the version of oozie I have) > >ErrorType.NON_TRANSIENT > >is only properly handled for exceptions thrown from start or end, but not > >from check. > Which Oozie version are you using? The ErrorType.NON_TRANSIENT should be > handled from check now too. > > > >But yes, this is all horribly documented on the oozie side. I only > >managed > >to cobble the above together through trial and error, and digging through > >the source. My own question on custom actions has also received no > >replies. > > > Thanks for the feedback Alexander. Oozie dev will take up an action item > to make the documentation piece clearer around custom scheduling. > > > > > > >On Mon, Jun 10, 2013 at 4:35 PM, Brad Miner <[email protected]> > >wrote: > > > >> 1. Is it possible to schedule a coordinator where the interval between > >>runs > >> is automatic based on success? > >> > >> Use case: this specific workflow self bootstraps with small iterative > >>units > >> of work and we would like for it to run the next one as soon as the > >> previous one has finished with as small of a gap as possible. I know I > >> could schedule it to have a reschedule interval of X (where X is the > >>best > >> case runtime) as a way around this but due to the runtime having a large > >> range this could cause a large backfill of coordinator actions that > >>would > >> be scheduled and I don't know the implications of this. Is there a > >> non-hacky way around this? > >> > >> 2. Is there a way to throw a specific error from a Java action which > >>would > >> cause the Oozie server to automatically retry the workflow? > >> > >> Use case: as it is we have several workflows that have Java actions in > >>them > >> and we would like to use the auto retry logic built into the Oozie > >>server. > >> Currently if the Java main dies due to a custom / standard exception it > >> does not trigger the auto retry and the documentation isn't very clear > >>on > >> how to bridge the gap. > >> > >> Thank you for any advice on either! > >> > >> Brad M. > >> > >
