[infinispan-issues] [JBoss JIRA] (ISPN-2896) org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly

[Pedro Ruivo (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Ruivo updated ISPN-2896:
------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/infinispan/infinispan/pull/1822


I think that bug is caused by the removeAsync when the value == 0.

Simplify code:
{code:java}
int refCount = refCountObject.intValue();
newValue = refCount - 1;
locksCache.replace(readLockKey, refCountObject, newValue);
if (newValue == 0) {
  locksCache.withFlags(Flag.IGNORE_RETURN_VALUES).removeAsync(readLockKey);
}
{code}

So, when the assertion is done, the value can be zero or one. In case of zero, we need to check if the key is really removed.
                
> org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly
> ------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-2896
>                 URL: https://issues.jboss.org/browse/ISPN-2896
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Lucene Directory
>    Affects Versions: 5.2.2.Final
>            Reporter: Anna Manukyan
>            Assignee: Sanne Grinovero
>              Labels: stable_embedded_query
>             Fix For: 5.3.0.CR1
>
>
> org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage  fails randomly. The error message is:
> {code}
> java.lang.AssertionError
> 	at org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage(DirectoryOnMultipleCachesTest.java:96)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:767)
> 	at org.testng.TestRunner.run(TestRunner.java:617)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> 	at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> 	at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> 	at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 	at java.lang.Thread.run(Thread.java:722)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira