[ https://issues.apache.org/jira/browse/OOZIE-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064742#comment-14064742 ]
Shwetha G S commented on OOZIE-1319: ------------------------------------ I have a question regarding this implementation(Sorry about the late ask) - Why does this require changes in CoordActionInputCheckXCommand, why the comparison with now and next nominal time? 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. Instead, shouldn't the change be in CoordActionReadyXCommand which picks all ready actions and picks latest and discard the rest? > "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)