Bug 918450 - org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly
Summary: org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesU...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 6.2.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks: 921984
TreeView+ depends on / blocked
 
Reported: 2013-03-06 09:25 UTC by Anna Manukyan
Modified: 2025-02-10 03:27 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
: 921984 (view as bug list)
Environment:
Last Closed: 2025-02-10 03:27:33 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-2896 0 Major Closed org.infinispan.lucene.DirectoryOnMultipleCachesTest.verifyIntendedLockCachesUsage fails randomly 2013-08-15 07:11:13 UTC

Description Anna Manukyan 2013-03-06 09:25:45 UTC 
The test randomly fails (but very often) with the error:

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)
Comment 1 JBoss JIRA Server 2013-05-16 09:39:14 UTC 
Pedro Ruivo <pedroruivo2> made a comment on jira ISPN-2896

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.
Comment 2 Tristan Tarrant 2013-06-26 09:38:36 UTC 
Resolved upstream
Comment 4 JBoss JIRA Server 2013-08-14 20:34:22 UTC 
Sanne Grinovero <sanne+jbossorg> updated the status of jira ISPN-2896 to Closed
Comment 6 Red Hat Bugzilla 2025-02-10 03:27:33 UTC 
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.
Note You need to log in before you can comment on or make changes to this bug.