[
https://issues.apache.org/jira/browse/OOZIE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13981725#comment-13981725
]
Robert Kanter commented on OOZIE-1319:
--------------------------------------
{quote}After oozie server is back up, when you run the second materialization,
previously materialized actions may already be in RUNNING state or even
"SUCCEEDED" state, therefore your "get_unscheduled_actions" query won't
retrieve them.{quote}
Isn't that the correct behavior? If the action is already running, then I
think we should not kill it.
In the second scenario, there would only be one WAITING action becuase the
older ones should be SKIPPED. My understanding of LAST_ONLY, is that if there
are any WAITING or READY actions in the past, they should all be SKIPPED except
for the latest one. WAITING or READY actions in the future should be
unaffected (though my patch doesn't do this yet).
{quote}Third point, your "GET_UNSCHEDULED_ACTIONS" query is retrieving all
actions regardless the execution order of the parent coord jobs.{quote}
It only runs "GET_UNSCHEDULED_ACTIONS" if the coordinator job's execution
strategy is LAST_ONLY; there's an if statement in {{handleLastOnly()}}.
> "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
>
>
> 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)
