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. >>
