[
https://issues.apache.org/jira/browse/OOZIE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14010654#comment-14010654
]
Bowen Zhang commented on OOZIE-1319:
------------------------------------
I don't see you dealing with the race condition between RecoveryService and
CoordMaterilalizeTriggerService.. When oozie server is back up after more than
an hour of downtime, you may only skip the first hour of actions, but you still
will materialize and run all actions with nominal times in the past one or
several hours during downtime since CoordActionInputCheckXCommand runs before
CoordMaterializationXCommand.
Second, you CoordActionInputCheckXCommand relies on a big assumption that the
latest action will get called first by CoordActionInputCheckXCommand since if
the second to the latest one gets called first in
CoordActionInputCheckXCommand, it will mark the latest action which is supposed
to run as "SKIPPED".
> "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
> Attachments: 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)
