[ https://issues.apache.org/jira/browse/OOZIE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890122#comment-16890122 ]
Andras Salamon commented on OOZIE-2566: --------------------------------------- Thanks for checking the patch [~pbacsko]. To be honest I'm not sure about the whole purpose of this specific test and I collected to many questions, so I uploaded a simple fix. * It seems to me there are two similar tests: {{TestCoordActionInputCheckXCommand.testCoordActionInputCheckXCommandUniqueness}} and {{TestCoordKillXCommand.testCoordKillXCommandUniqueness}}. Why do we test these two methods specifically? During the tests we replace the {{execute()}} method with a simple sleep, so it's more like a {{CallableQueue}} test. We have several {{TestCallableQueue.testQueueUniqueness*}} tests, what is the added value here? * If we only want to test the uniqueness then we could simplify the tests. We don't really need to execute the tests, we could just queue them and check the {{getUniqueDump() }} but again why is it better than the {{TestCallableQueue}} tests? > TestCoordActionInputCheckXCommand.testCoordActionInputCheckXCommandUniqueness() > is flaky > ---------------------------------------------------------------------------------------- > > Key: OOZIE-2566 > URL: https://issues.apache.org/jira/browse/OOZIE-2566 > Project: Oozie > Issue Type: Sub-task > Components: core > Reporter: Peter Bacsko > Assignee: Andras Salamon > Priority: Major > Attachments: OOZIE-2566-01.patch > > > The testcase testCoordActionInputCheckXCommandUniqueness is unstable. > We add three XCommands with the same actionId (entityKeys are different) into > the CallableQueueService. Only the first XCommand is expected to run. > The reason why sometimes either the 2nd or 3rd XCommand executes is because > as soon as the first starts to run, its removed from the {{uniqueCallables}} > map immediately. If the first scheduled task runs quickly, then either the > 2nd or 3rd XCommand has the chance to get scheduled. > Step by step: > 1. Schedule first XCommand > 2. XCommand is added to {{uniqueCallables}} > 3. Schedule second XCommand > 4. First XCommand starts to run in the thread pool and removes itself from > {{uniqueCallables}} (see {{CallableWrapper.run()}}) > 5. Second XCommand can successfully add itself to {{uniqueCallables}} > 6. Second XCommand starts to run > Please clarify whether this is the expected behavior of CallableQueueService. > If not, then moving {{removeFromUniqueCallables()}} to the finally block > solves the problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)