[
https://issues.apache.org/jira/browse/OOZIE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Bacsko updated OOZIE-2566:
--------------------------------
Description:
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.
was:
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.
> TestCoordActionInputCheckXCommand.testCoordActionInputCheckXCommandUniqueness()
> is flaky
> ----------------------------------------------------------------------------------------
>
> Key: OOZIE-2566
> URL: https://issues.apache.org/jira/browse/OOZIE-2566
> Project: Oozie
> Issue Type: Bug
> Components: core
> Reporter: Peter Bacsko
> Assignee: Peter Bacsko
> Priority: Minor
>
> 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
(v6.3.4#6332)
