[
https://issues.apache.org/jira/browse/OOZIE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067134#comment-15067134
]
Rohini Palaniswamy commented on OOZIE-2394:
-------------------------------------------
bq. None of wfstart,end command uses eager and eager verify. So, I don't think
that there will be any performance issue.
bq. No, I don't think so. This information is done at client side. I guess
curator framework don't even have to call the ZK to check that.
Sounds good. But I would like to see the stress test run and confirmed that
there is no performance regression before giving +1 for this patch.
bq. Only issue is see is https://issues.apache.org/jira/browse/OOZIE-1922. Will
fix this as well.
OOZIE-1922 will have to be committed before this patch can have +1 as this
change without that patch will totally break for MemoryLocksService. Also you
will have to verify if curator lock also has any such issues.
> 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)
