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