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

Robert Kanter commented on OOZIE-2394:
--------------------------------------

A few minor things:
# XCommand has an else statement that now has a new line
{code}
} else {
{code}
became
{code}
}
else {
{code}
Can you put that back?
# There's a lot of formatting changes in areas of the code that weren't 
changed.  Don't we generally not fix those unless actually changing that part 
of the code?
# It would be good to make at least a simple test to show that XCommands and 
the locking is reentrant.  Perhaps just create a DummyXCommand that 
synchronously calls a Dummy2XCommand and both have the same entity key or 
something like that?  The test should probably have some kind of timeout in 
case this ever breaks.

> 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)

Reply via email to