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)