Are you setting user retry attributes on the action node you want to retry? This will force ANY error to cause a retry, it's not clear from your email if you only wanted to catch specific ones or not.
http://archive.cloudera.com/cdh4/cdh/4/oozie/WorkflowFunctionalSpec.html#a18_User-Retry_for_Workflow_Actions_since_Oozie_3.1 -Paul -----Original Message----- From: Brad Miner [mailto:[email protected]] Sent: Tuesday, June 11, 2013 6:53 PM To: [email protected] Subject: Re: Quick questions regarding scheduling Bumping this question. I have been digging through the source to find the routing for the retry and I think I might have a solution for this but does the lack of reply on these two questions mean no one has run into either of these yet? On Mon, Jun 10, 2013 at 3: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. >
