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