[ 
https://issues.apache.org/jira/browse/OOZIE-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119480#comment-14119480
 ] 

Shwetha G S commented on OOZIE-1581:
------------------------------------

[~puru], thanks for checking this 
{quote}
And i think that is a correct behavior, rerunning of WF haven't triggered 
rerunning of coord action. Running for coord action does lot of other things 
beside submitting new WF like input dependency check, coord definition update ( 
if needed), delete output ( if needed). So it may not be correct to say coord 
action has rerun if we rerun WF.
{quote}
Isn't workflow re-run same as coord action re-run with no refresh, no 
cleanup(which are anyway options in coord action re-run)? Its just that it 
doesn't handle concurrency check, but nothing else changes.

Assuming that the workflow and coord action are killed initially, and the user 
re-runs the workflow, workflow moves to running state, but coord action remains 
in killed state. Finally, if the workflow succeeds, we change the coord action 
to succeeded(yes, we do this already). So, the coord action changes from killed 
to succeeded. So, my question is why not update the coord action status when 
workflow is running as well?

> Workflow performance optimizations
> ----------------------------------
>
>                 Key: OOZIE-1581
>                 URL: https://issues.apache.org/jira/browse/OOZIE-1581
>             Project: Oozie
>          Issue Type: Improvement
>          Components: workflow
>    Affects Versions: trunk
>            Reporter: Mona Chitnis
>            Assignee: Mona Chitnis
>             Fix For: 4.1.0
>
>         Attachments: OOZIE-1581-2.patch, OOZIE-1581-final.patch, 
> OOZIE-1581-r6.patch, OOZIE-1581-r6.patch, OOZIE-1581-r7.patch, 
> OOZIE-1581.patch
>
>
> Creating a combo JIRA for small performance optimizations.
> 1. changing from asynchronous action start to a synchronous one, to overcome 
> the undue delay in transitioning from ::start:: control node to the actual 
> first node, owing to a loaded queue. This delay has been observed to be close 
> to 30 min at times in stress conditions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to