[
https://issues.apache.org/jira/browse/OOZIE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065774#comment-14065774
]
Robert Kanter commented on OOZIE-1319:
--------------------------------------
{quote}CoordActionInputCheckXCommand, why the comparison with now and next
nominal time? {quote}
As for what the LAST_ONLY option was supposed to do, we never actually had any
very specific documentation. To try to keep this from becoming very
complicated (both to implement and to use), at some point I made the decision
that the LAST_ONLY will look at the nominal time of the next nominal time. In
essence, you can think of this like having the timeout set to the interval, but
instead of being TIMEDOUT (which results in a "bad" end state for the job), it
becomes SKIPPED (which results in a "good" end state for the job). I think
this decision makes sense anyway because if the next action is ready to run,
the previous action should have either already ran or should not run.
{quote}Take an example of an hourly coord and there are coord actions for 8th,
9th, 10th and 11th hour in WAITING state. The expectation of LAST_ONLY is that
among the ready actions(all dependencies met), it runs only the last one. But
with now and next nominal time check, CoordActionInputCheckXCommand marks 8th,
9th and 10th as SKIPPED and 11th will remain in WAITING state. If the
dependencies are available late consistently, the same thing continues(in 12th
hour, 11th will be marked SKIPPED) and so on and none of the instances for this
coord will run.{quote}
If the dependencies are met, then shouldn't the 11th transition from WAITING to
READY to RUNNING etc?
But yes, I suppose if you had a job where the data was consistently late by
over one interval of the frequency, and the timeout was set high enough, then
it is possible that no actions will actually run. I'm not sure of a good way
to handle this scenario, but if you have any ideas, please file a JIRA.
> "LAST_ONLY" in execution control for coordinator job still runs all the
> actions
> -------------------------------------------------------------------------------
>
> Key: OOZIE-1319
> URL: https://issues.apache.org/jira/browse/OOZIE-1319
> Project: Oozie
> Issue Type: Bug
> Reporter: Bowen Zhang
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-1319.patch, OOZIE-1319.patch, OOZIE-1319.patch,
> OOZIE-1319.patch, OOZIE-1319.patch, OOZIE-1319.patch, OOZIE-1319.patch,
> oozie-1319.patch
>
>
> In execute() of CoordJobGetReadyActionsJPAExecutor.java, once we retrieve the
> top item from a "LIFO" query result, we do not discard or delete the
> remaining items from the result list. As a result, the next time execute() is
> invoked, we will be retrieving the next item in line. Consequently, LAST_ONLY
> strategy will also execute all ready actions for a given coordinator job,
> making it no different than LIFO.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
