So, can anyone confirm whether this is bug or not?
On Mon, Jun 24, 2013 at 10:22 AM, Alexander Taggart <[email protected]>wrote: > 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. >> >> >> >> >
