[JBoss JIRA] (ISPN-6952) JCacheTwoCachesBasicOpsTest.testRemovedListener fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6952?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6952:
-------------------------------
Attachment: JCacheTwoCachesBasicOpsTest_20161106.log.gz
> JCacheTwoCachesBasicOpsTest.testRemovedListener fails
> -----------------------------------------------------
>
> Key: ISPN-6952
> URL: https://issues.jboss.org/browse/ISPN-6952
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Reporter: Sebastian Łaskawiec
> Assignee: Galder Zamarreño
> Priority: Critical
> Attachments: JCacheTwoCachesBasicOpsTest_20161106.log.gz
>
>
> http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=804...
> {noformat}
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> 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:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115)
> at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:205)
> at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108)
> at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> ------- Stdout: -------
> [TestSuiteProgress] Test starting: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> 12:50:19,634 ERROR (testng-JCacheTwoCachesBasicOpsTest) [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[TestSuiteProgress] Tests succeeded: 19, failed: 1, skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (ISPN-7172) Total order caches can hang during join
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7172:
----------------------------------
Summary: Total order caches can hang during join
Key: ISPN-7172
URL: https://issues.jboss.org/browse/ISPN-7172
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite - Core
Affects Versions: 9.0.0.Alpha4
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 9.0.0.Beta1
When two nodes join a cache in quick sequence, it's possible for a {{CacheTopologyControlCommand}} to arrive between {{LocalTopologyManagerImpl}} adding the {{LocalCacheStatus}} to the {{runningCaches}} map, but before it calling {{cacheStatus.getTopologyUpdatesExecutor().executeAsync(() -> joinFuture)}} to block topology updates.
This exposes a bug in the way {{LimitedExecutor}} wraps a {{WithinThreadExecutor}}, which causes {{SyncPrepareUseSynchronizationTotalOrderTest}} (and possibly other total order tests) to hang:
{noformat}
"testng-SyncPrepareUseSynchronizationTotalOrderTest" #15 prio=5 os_prio=0 tid=0x00007fc674b74000 nid=0x2f3f waiting on condition [0x00007fc626682000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000829d03a0> (a java.util.concurrent.CompletableFuture$Signaller)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1687)
at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3320)
at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1767)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1907)
at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
at org.infinispan.executors.LimitedExecutor.execute(LimitedExecutor.java:70)
at org.infinispan.executors.LimitedExecutor.executeAsync(LimitedExecutor.java:96)
at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:141)
at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:121)
at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547)
- locked <0x00000000829d0520> (a org.infinispan.factories.ComponentRegistry)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:808)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:639)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:590)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:422)
at org.infinispan.test.MultipleCacheManagersTest.getCaches(MultipleCacheManagersTest.java:248)
at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:257)
at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:266)
at org.infinispan.tx.totalorder.simple.BaseSimpleTotalOrderTest.createCacheManagers(BaseSimpleTotalOrderTest.java:326)
at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:109)
at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:119)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (ISPN-7171) LIRS eviction strategy leaks without cache hits
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7171?page=com.atlassian.jira.plugin.... ]
William Burns resolved ISPN-7171.
---------------------------------
Resolution: Rejected
Unfortunately this is the way that LIRS works. In this case there can be a large number of non resident nodes when the resident LIR nodes are not accessed. You can read up on the paper at [1].
We are actually replacing our eviction algorithm in 9.0 and it will not have this issue. It is based on TinyLFU using Caffeine [2] [3]
[1] web.cse.ohio-state.edu/hpcs/WWW/HTML/publications/abs02-6.html
[2] https://arxiv.org/pdf/1512.00727.pdf
[3] https://github.com/ben-manes/caffeine
> LIRS eviction strategy leaks without cache hits
> -----------------------------------------------
>
> Key: ISPN-7171
> URL: https://issues.jboss.org/browse/ISPN-7171
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.4.Final
> Reporter: Ryan Gustafson
> Attachments: BoundedInfinispanCacheTest.java
>
>
> When using a size bounded cache with the LIRS eviction strategy and there are no cache hits, the cache will leak until OOM is triggered. This makes LIRS a risky choice for a bounded cache in which a large number of puts can occur before the arrival of a subsequent cache hit. At worst the application can go OOM, and at best it keeps working but suffers from randomly excessive heap usage.
> See attached JUnit test class. There are 5 cases in the test:
> # A size bounded cache using LRU with only puts does not leak. PASSES
> # A size bounded cache using LIRS with only puts does leak. FAILS
> # A size bounded cache using LIRS with intermittent cache hits does not leak. PASSES
> # A size bounded cache using LIRS with intermittent cache misses does leak. FAILS
> # A size bounded cache using LIRS with a single cache hit and subsequent intermittent cache misses does leak. FAILS
> The test was written assuming Java 8 and Infinispan 8.2.4. It should be run using the -Xmx64m JVM argument to limit heap size. Each test method should be run separately. The FAILING tests will throw OOME or have very slow progress with excessive garbage collection. The PASSING tests will run quickly through 1,000,000 cache puts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months
[JBoss JIRA] (ISPN-7171) LIRS eviction strategy leaks without cache hits
by Ryan Gustafson (JIRA)
Ryan Gustafson created ISPN-7171:
------------------------------------
Summary: LIRS eviction strategy leaks without cache hits
Key: ISPN-7171
URL: https://issues.jboss.org/browse/ISPN-7171
Project: Infinispan
Issue Type: Bug
Affects Versions: 8.2.4.Final
Reporter: Ryan Gustafson
Attachments: BoundedInfinispanCacheTest.java
When using a size bounded cache with the LIRS eviction strategy and there are no cache hits, the cache will leak until OOM is triggered. This makes LIRS a risky choice for a bounded cache in which a large number of puts can occur before the arrival of a subsequent cache hit. At worst the application can go OOM, and at best it keeps working but suffers from randomly excessive heap usage.
See attached JUnit test class. There are 5 cases in the test:
# A size bounded cache using LRU with only puts does not leak. PASSES
# A size bounded cache using LIRS with only puts does leak. FAILS
# A size bounded cache using LIRS with intermittent cache hits does not leak. PASSES
# A size bounded cache using LIRS with intermittent cache misses does leak. FAILS
# A size bounded cache using LIRS with a single cache hit and subsequent intermittent cache misses does leak. FAILS
The test was written assuming Java 8 and Infinispan 8.2.4. It should be run using the -Xmx64m JVM argument to limit heap size. Each test method should be run separately. The FAILING tests will throw OOME or have very slow progress with excessive garbage collection. The PASSING tests will run quickly through 1,000,000 cache puts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 2 months