[jira] [Comment Edited] (OOZIE-2394) Oozie can execute command without holding lock

["Purshotam Shah (JIRA)" <ji...@apache.org>]

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

Purshotam Shah edited comment on OOZIE-2394 at 1/26/16 6:25 PM:
----------------------------------------------------------------

	{quote}
	On second thoughts, I think it would be good to retain the execute synchronous code in XCommand. It can be enhanced to avoid loadState() and the objects passed in constructor itself further saving time and being more performant. So can we just set synchronous to false when requeuing?
	{quote}
	We should leave it for command to decide. If an object is passed, then simple check in loadState can exclude loading of that object.
	Lot of time loadState loads multiple objects. Skipping loadState won't work for those commands.
Example.
{code:title=ActionStartXCommand.java}
    protected void loadState() throws CommandException {
        try {
            jpaService = Services.get().get(JPAService.class);
            if (jpaService != null) {
                if (wfJob == null) {
                    this.wfJob = WorkflowJobQueryExecutor.getInstance().get(WorkflowJobQuery.GET_WORKFLOW, jobId);
                }
                this.wfAction = WorkflowActionQueryExecutor.getInstance().get(WorkflowActionQuery.GET_ACTION, actionId);
                LogUtils.setLogInfo( wfJob);
                LogUtils.setLogInfo(wfAction);
            }
            else {
                throw new CommandException(ErrorCode.E0610);
            }
        }
        catch (XException ex) {
            throw new CommandException(ex);
        }
    }
{code}	


was (Author: puru):
	{quote}
	On second thoughts, I think it would be good to retain the execute synchronous code in XCommand. It can be enhanced to avoid loadState() and the objects passed in constructor itself further saving time and being more performant. So can we just set synchronous to false when requeuing?
	{quote}
	We should leave it for command to decide. If an object is passed, then simple check in loadState can exclude loading of that object.
	Lot of time loadState loads multiple objects. Skipping loadState won't work for those commands.
Example.
{code:title=ActionStartXCommand.java}
    protected void loadState() throws CommandException {
        try {
            jpaService = Services.get().get(JPAService.class);
            if (jpaService != null) {
                if (wfJob == null) {
                    this.wfJob = WorkflowJobQueryExecutor.getInstance().get(WorkflowJobQuery.GET_WORKFLOW, jobId);
                }
                this.wfAction = WorkflowActionQueryExecutor.getInstance().get(WorkflowActionQuery.GET_ACTION, actionId);
                LogUtils.setLogInfo( wfJob);
                LogUtils.setLogInfo(wfAction);
            }
            else {
                throw new CommandException(ErrorCode.E0610);
            }
        }
        catch (XException ex) {
            throw new CommandException(ex);
        }
    }
	

> Oozie can execute command without holding lock
> ----------------------------------------------
>
>                 Key: OOZIE-2394
>                 URL: https://issues.apache.org/jira/browse/OOZIE-2394
>             Project: Oozie
>          Issue Type: Bug
>            Reporter: Purshotam Shah
>            Assignee: Purshotam Shah
>            Priority: Critical
>         Attachments: OOZIE-2394-V1.patch
>
>
> To speedup job submission ( not the the forked actions) we create workflow actions synchronously. We call ActionStartXCommand from SignalXCommand by setting isSynchronous = true. This will bypass lock acquiring, which is Ok, SignalXCommand will have the job lock.
> If there is transient error. Same command is requeued which will have isSynchronous flag set to true.
> Requeued command will wake-up and started executing without acquiring lock. If the job submission takes more than 2 min, then we might have issue.
> Action recovery is set to 2 min ( default), Recovery service will run and submitted new the command. since the first command didn't acquire any lock. Recovery will be able to run the new command.
> We will have two same command running parallely.
> All our commands are reentrant, we don't have to have set synchronized flag to run multiple command from same thread.
> Because of reentrant, command running in same thread should be able to acquire same lock.



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