falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pallavi Rao (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FALCON-1598) Flaky test : EntityManagerJerseyIT.testDuplicateDeleteCommands
Date Thu, 03 Dec 2015 12:07:11 GMT

    [ https://issues.apache.org/jira/browse/FALCON-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037716#comment-15037716

Pallavi Rao commented on FALCON-1598:

If there is an exception while obtaining locks, the exception will be caught anyway, because
it is an nested try-catch. The parent try-catch will take care of it and one thread should
see an exception.
try {
            try {
                Entity entityObj = EntityUtil.getEntity(type, entity);
                obtainEntityLocks(entityObj, "delete", tokenList);
            } catch (EntityNotRegisteredException e) { // already deleted
                return new APIResult(APIResult.Status.SUCCEEDED,
                        entity + "(" + type + ") doesn't exist. Nothing to do");

            return new APIResult(APIResult.Status.SUCCEEDED,
                    entity + "(" + type + ") removed successfully " + removedFromEngine);
        } catch (Throwable e) {
            throw FalconWebException.newException(e, Response.Status.BAD_REQUEST);
        } finally {
            releaseEntityLocks(entity, tokenList);

The test is failing because of thread timing. Sometimes, by the time the second thread tries
to obtain a lock, the first thread would finish its work and release the lock, resulting in
a "SUCCESS" for both the cases.

If the suggestion is to change the current behavior to make concurrent requests behave similar
to subsequent requests, in an idempotent manner, then, we can consider it (may be in another
JIRA), and make code changes to ensure all APIs behave consistently.

But, if the suggestion is to change the test to expect "SUCCESS" for both threads. Then, it
wouldn't be testing the "expected" behavior. right?

So, may be we should just let this patch fix the test and have another JIRA to make concurrent
requests idempotent? If we can achieve idempotency without complexity in code, sounds good
to me.

> Flaky test : EntityManagerJerseyIT.testDuplicateDeleteCommands
> --------------------------------------------------------------
>                 Key: FALCON-1598
>                 URL: https://issues.apache.org/jira/browse/FALCON-1598
>             Project: Falcon
>          Issue Type: Sub-task
>          Components: tests
>    Affects Versions: 0.8
>            Reporter: Balu Vellanki
>            Assignee: Narayan Periwal
>             Fix For: trunk
>         Attachments: FALCON-1598.patch
> testDuplicateDeleteCommands fails occasionally with following error
> {code}
> Tests run: 28, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 51.226 sec <<<
FAILURE! - in org.apache.falcon.resource.EntityManagerJerseyIT
> testDuplicateDeleteCommands(org.apache.falcon.resource.EntityManagerJerseyIT)  Time elapsed:
0.643 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<400> but was:<200>
> at org.testng.Assert.fail(Assert.java:89)
> at org.testng.Assert.failNotEquals(Assert.java:489)
> at org.testng.Assert.assertEquals(Assert.java:118)
> at org.testng.Assert.assertEquals(Assert.java:365)
> at org.testng.Assert.assertEquals(Assert.java:375)
> at org.apache.falcon.resource.TestContext.assertFailure(TestContext.java:439)
> at org.apache.falcon.resource.EntityManagerJerseyIT.testDuplicateCommandsResponse(EntityManagerJerseyIT.java:629)
> at org.apache.falcon.resource.EntityManagerJerseyIT.testDuplicateDeleteCommands(EntityManagerJerseyIT.java:622)
> {code}
> Looking at the code, I found that the test expects one of the two delete commands to
fail when attempting to delete same cluster. I think the premise of the test is incorrect.
If one of the two commands are expected to fail, isnt that breaking Falcon's idempotent behavior?

This message was sent by Atlassian JIRA

View raw message