[
https://issues.apache.org/jira/browse/PHOENIX-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-6284:
----------------------------------
Description:
UpgradeIT.testConcurrentUpgradeThrowsUpgradeInProgressException is sometimes
failing with error logs:
e.g
https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/166/testReport/org.apache.phoenix.end2end/UpgradeIT/MatrixBuild___Matrix___HBASE_PROFILE____2_1____BuildAndTest___testConcurrentUpgradeThrowsUprgadeInProgressException/
{code:java}
java.lang.AssertionError: One and only one thread should have acquired the
mutex . Actual: true
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failEquals(Assert.java:187)
at org.junit.Assert.assertNotEquals(Assert.java:163)
at
org.apache.phoenix.end2end.UpgradeIT.testConcurrentUpgradeThrowsUprgadeInProgressException(UpgradeIT.java:237)
{code}
While testing if 2 threads can simultaneously acquire lock, we release the lock
immediately in finally for individual thread if it had acquired the mutex. This
can lead to failure if one of the threads starts executing (due to slowness)
only after the other thread releases mutex cell. In that case, the sequence of
mutex acquisition would be:
Thread1 acquires -> Thread1 releases -> Thread2 acquires -> Thread2 releases
Because of this sequence, the above mentioned AssertionError can occur.
was:
UpgradeIT.testConcurrentUpgradeThrowsUpgradeInProgressException is sometimes
failing with error logs:
{code:java}
java.lang.AssertionError: One and only one thread should have acquired the
mutex . Actual: true
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failEquals(Assert.java:187)
at org.junit.Assert.assertNotEquals(Assert.java:163)
at
org.apache.phoenix.end2end.UpgradeIT.testConcurrentUpgradeThrowsUprgadeInProgressException(UpgradeIT.java:237)
{code}
While testing if 2 threads can simultaneously acquire lock, we release the lock
immediately in finally for individual thread if it had acquired the mutex. This
can lead to failure if one of the threads starts executing (due to slowness)
only after the other thread releases mutex cell. In that case, the sequence of
mutex acquisition would be:
Thread1 acquires -> Thread1 releases -> Thread2 acquires -> Thread2 releases
Because of this sequence, the above mentioned AssertionError can occur.
> Flaky test UpgradeIT.testConcurrentUpgradeThrowsUpgradeInProgressException
> --------------------------------------------------------------------------
>
> Key: PHOENIX-6284
> URL: https://issues.apache.org/jira/browse/PHOENIX-6284
> Project: Phoenix
> Issue Type: Test
> Affects Versions: 5.0.0, 4.15.0
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
> Fix For: 5.1.0, 4.16.0
>
>
> UpgradeIT.testConcurrentUpgradeThrowsUpgradeInProgressException is sometimes
> failing with error logs:
> e.g
> https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/166/testReport/org.apache.phoenix.end2end/UpgradeIT/MatrixBuild___Matrix___HBASE_PROFILE____2_1____BuildAndTest___testConcurrentUpgradeThrowsUprgadeInProgressException/
> {code:java}
> java.lang.AssertionError: One and only one thread should have acquired the
> mutex . Actual: true
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failEquals(Assert.java:187)
> at org.junit.Assert.assertNotEquals(Assert.java:163)
> at
> org.apache.phoenix.end2end.UpgradeIT.testConcurrentUpgradeThrowsUprgadeInProgressException(UpgradeIT.java:237)
> {code}
> While testing if 2 threads can simultaneously acquire lock, we release the
> lock immediately in finally for individual thread if it had acquired the
> mutex. This can lead to failure if one of the threads starts executing (due
> to slowness) only after the other thread releases mutex cell. In that case,
> the sequence of mutex acquisition would be:
> Thread1 acquires -> Thread1 releases -> Thread2 acquires -> Thread2 releases
> Because of this sequence, the above mentioned AssertionError can occur.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
