You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Shwetha G S (JIRA)" <ji...@apache.org> on 2014/08/25 12:33:59 UTC

[jira] [Commented] (OOZIE-1581) Workflow performance optimizations

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

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

In SignalXCommand:
{code}
        // Changing to synchronous call from asynchronous queuing to prevent
        // undue delay from between end of previous and start of next action
        if (wfJob.getStatus() != WorkflowJob.Status.RUNNING
                && wfJob.getStatus() != WorkflowJob.Status.SUSPENDED) {
            // only for asynchronous actions, parent coord action's external id will
            // persisted and following update will succeed.
            updateParentIfNecessary(wfJob);
            new WfEndXCommand(wfJob).call(); // To delete the WF temp dir
        }
{code}
[~chitnis], why is there check on status while updating parent?

For the usecase where coord action and the workflow is killed, a re-run of the workflow moves the status to running, but coord action remains in killed state because of this?

> 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.2#6252)