[jira] [Updated] (OOZIE-2566) TestCoordActionInputCheckXCommand.testCoordActionInputCheckXCommandUniqueness() is flaky

["Peter Bacsko (JIRA)" <ji...@apache.org>]

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