You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2015/11/25 04:11:10 UTC

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

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

Hadoop QA commented on OOZIE-2394:
----------------------------------

Testing JIRA OOZIE-2394

Cleaning local git workspace

----------------------------

{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.    {color:green}+1{color} the patch does not introduce any @author tags
.    {color:green}+1{color} the patch does not introduce any tabs
.    {color:green}+1{color} the patch does not introduce any trailing spaces
.    {color:green}+1{color} the patch does not introduce any line longer than 132
.    {color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.    {color:green}+1{color} the patch does not seem to introduce new RAT warnings
{color:green}+1 JAVADOC{color}
.    {color:green}+1{color} the patch does not seem to introduce new Javadoc warnings
{color:green}+1 COMPILE{color}
.    {color:green}+1{color} HEAD compiles
.    {color:green}+1{color} patch compiles
.    {color:green}+1{color} the patch does not seem to introduce new javac warnings
{color:green}+1 BACKWARDS_COMPATIBILITY{color}
.    {color:green}+1{color} the patch does not change any JPA Entity/Colum/Basic/Lob/Transient annotations
.    {color:green}+1{color} the patch does not modify JPA files
{color:red}-1 TESTS{color}
.    Tests run: 1698
.    Tests failed: 7
.    Tests errors: 0

.    The patch failed the following testcases:

.      testActionCheckTransientDuringLauncher(org.apache.oozie.command.wf.TestActionCheckXCommand)
.      testPauseBundleAndCoordinator(org.apache.oozie.service.TestPauseTransitService)
.      testBundlePauseExtendMaterializesCoordinator(org.apache.oozie.command.bundle.TestBundleChangeXCommand)
.      testbulkWfKillSuccess(org.apache.oozie.command.wf.TestBulkWorkflowXCommand)
.      testForNoDuplicates(org.apache.oozie.event.TestEventGeneration)
.      testRerunVariableSub(org.apache.oozie.command.wf.TestReRunXCommand)
.      testSamplers(org.apache.oozie.util.TestMetricsInstrumentation)

{color:green}+1 DISTRO{color}
.    {color:green}+1{color} distro tarball builds with the patch 

----------------------------
{color:red}*-1 Overall result, please check the reported -1(s)*{color}


The full output of the test-patch run is available at

.   https://builds.apache.org/job/oozie-trunk-precommit-build/2600/

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