You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@oozie.apache.org by Alexander Taggart <ma...@ataggart.ca> on 2013/07/02 16:15:09 UTC

Re: Custom ActionExecutor

Does anyone have any input regarding the above?


On Thu, May 23, 2013 at 4:58 PM, Alexander Taggart <ma...@ataggart.ca> wrote:

> I'm trying to implement a custom ActionExecutor and am having a hell of a
> time trying to figure out exactly how to communicate back to oozie.
>
> Specifically, I need to be able to force the action to require human
> intervention before continuing.  In other words, not traversing down the
> error path, nor retrying the action.  I also need some way of sending back
> some text output to the user via the oozie console.
>
> Between the 4 different ErrorType enums and the 12 different
> WorkflowAction.Status enums and the plethora of undocumented Context and
> WorkflowAction methods to convey state back to ozzie, I'm at a loss as to
> how any of this is supposed to work.
>
> And yes, I have read the one doc page on this topic (
> http://oozie.apache.org/docs/3.3.2/DG_CustomActionExecutor.html). It
> didn't help.  It also suggests a distinction between synchronous and
> asynchronous actions but says nothing about how that distinction is
> implemented.
>
> So far I've tried various combinations of the following:
>
> 1. context.setEndData: Takes a Status enum, but will only accept OK, ERROR
> or KILLED. (Aside: the associated javadocs omit FAILED as an option).
>
> 2. context.setExecutionData: it accepts an external status, thus just
> moves the problem to end(...).  Also, if setting my text output into the
> Properties object, I see nothing about it in the oozie web console.
>
> 3. throwing an ActionExecutorException with ErrorType.NON_TRANSIENT. This
> seems work when it is thrown from inside start(...), but not when thrown
> from inside check(...).  By "work", I mean that the workflow status is
> SUSPENDED, and the action status is START_MANUAL.
>
> 4. calling registerError with a custom exception and
> ErrorType.NON_TRANSIENT, and throwing that from inside check(...); same
> result as above.
>
> So, how exactly are we to communicate the custom state of an action back
> to oozie, particularly from the check(...) method?
>
>
>  - Alex
>