[JBoss JIRA] (ISPN-6104) Cache.Purge issues
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-6104?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-6104:
--------------------------------
Affects Version/s: 8.1.0.Final
> Cache.Purge issues
> ------------------
>
> Key: ISPN-6104
> URL: https://issues.jboss.org/browse/ISPN-6104
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.0.Final
> Reporter: Martin Gencur
> Assignee: Vladimir Blagojevic
>
> Currently, there are the following issues with the "Purge cache data" button:
> 1) The Purge operation only copies entries to the cache store, it does not remove the from the cache itself. So the cache remains full. Checked with cache.withFlags(Flag.SKIP_CACHE_LOAD).get() after I performed the Purge operation and still got the entries. The JMX stats also display entries in the cache.
> 2) The button is available even though the cache is attached to the remote endpoint and hence available to clients. It should only be available after the cache is detached from the endpoint.
> 3) The confirmation dialog for the operation always says "Purging cache xyCache will passivate all its cache entries." even though there's no cache store defined for the cache. This might lead users to expectations that their data will be stored somewhere. But if there's no cache store, the data will be lost. In this case, it would be better to show a warning that their data will be lost after performing the operation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6104) Cache.Purge issues
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-6104?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-6104:
--------------------------------
Description:
Currently, there are the following issues with the "Purge cache data" button:
1) The Purge operation only copies entries to the cache store, it does not remove the from the cache itself. So the cache remains full. Checked with cache.withFlags(Flag.SKIP_CACHE_LOAD).get() after I performed the Purge operation and still got the entries. The JMX stats also display entries in the cache.
2) The button is available even though the cache is attached to the remote endpoint and hence available to clients. It should only be available after the cache is detached from the endpoint.
3) The confirmation dialog for the operation always says "Purging cache xyCache will passivate all its cache entries." even though there's no cache store defined for the cache. This might lead users to expectations that their data will be stored somewhere. But if there's no cache store, the data will be lost. In this case, it would be better to show a warning that their data will be lost after performing the operation.
was:
Currently, there are the following issues with the "Purge cache data" button:
1) The button is available even though the cache is attached to the remote endpoint and hence available to clients. It should only be available after the cache is detached from the endpoint.
2) The confirmation dialog for the operation always says "Purging cache xyCache will passivate all its cache entries." even though there's no cache store defined for the cache. This might lead users to expectations that their data will be stored somewhere. But if there's no cache store, the data will be lost. In this case, it would be better to show a warning that their data will be lost after performing the operation.
> Cache.Purge issues
> ------------------
>
> Key: ISPN-6104
> URL: https://issues.jboss.org/browse/ISPN-6104
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Martin Gencur
> Assignee: Vladimir Blagojevic
>
> Currently, there are the following issues with the "Purge cache data" button:
> 1) The Purge operation only copies entries to the cache store, it does not remove the from the cache itself. So the cache remains full. Checked with cache.withFlags(Flag.SKIP_CACHE_LOAD).get() after I performed the Purge operation and still got the entries. The JMX stats also display entries in the cache.
> 2) The button is available even though the cache is attached to the remote endpoint and hence available to clients. It should only be available after the cache is detached from the endpoint.
> 3) The confirmation dialog for the operation always says "Purging cache xyCache will passivate all its cache entries." even though there's no cache store defined for the cache. This might lead users to expectations that their data will be stored somewhere. But if there's no cache store, the data will be lost. In this case, it would be better to show a warning that their data will be lost after performing the operation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6098) LockManagerTest.testMultipleCounterStripped random failures
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-6098?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-6098:
-----------------------------------
Agree about the ExecutorService. I'm going to create a loop to see if I can catch anything.
> LockManagerTest.testMultipleCounterStripped random failures
> -----------------------------------------------------------
>
> Key: ISPN-6098
> URL: https://issues.jboss.org/browse/ISPN-6098
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 8.2.0.Beta1
>
>
> Doesn't appear to fail in CI, but I did get a couple failures running the test on my machine:
> {noformat}
> 17:42:29,998 ERROR (testng-LockManagerTest:) [UnitTestTestNGListener] Test testMultipleCounterStripped(org.infinispan.lock.LockManagerTest) failed.
> java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_60]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_60]
> at org.infinispan.lock.LockManagerTest.doMultipleCounterTest(LockManagerTest.java:193) ~[test-classes/:?]
> at org.infinispan.lock.LockManagerTest.testMultipleCounterStripped(LockManagerTest.java:67) ~[test-classes/:?]
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 60 seconds for key key-6 and requestor Thread[pool-1127-thread-4,5,main]. Lock is held by null
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236) ~[classes/:?]
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$CompositeLockPromise.lock(DefaultLockManager.java:305) ~[classes/:?]
> at org.infinispan.lock.LockManagerTest.lambda$doMultipleCounterTest$483(LockManagerTest.java:163) ~[test-classes/:?]
> ... 4 more
> {noformat}
> In another run, I got a deadlock that I think is related in {{InfinispanLockTest}}:
> {noformat}
> "testng-InfinispanLockTest" #19 prio=5 os_prio=0 tid=0x00007ff7f0eeb800 nid=0x4f5d waiting on condition [0x00007ff770da5000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0000000084202448> (a java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at org.infinispan.lock.InfinispanLockTest.testSingleCounter(InfinispanLockTest.java:262)
> 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.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x0000000082875cc0> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "pool-1011-thread-7" #9840 prio=5 os_prio=0 tid=0x00007ff7380da000 nid=0x75f7 waiting on condition [0x00007ff698409000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000842020d8> (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:1695)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1775)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:74)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319)
> at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243)
> at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x00000000842021f8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> "pool-1011-thread-6" #9839 prio=5 os_prio=0 tid=0x00007ff738130800 nid=0x75f6 waiting on condition [0x00007ff699c21000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000842023a0> (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:1695)
> at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3323)
> at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1775)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:74)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lock(InfinispanLock.java:319)
> at org.infinispan.lock.InfinispanLockTest.lambda$testSingleCounter$509(InfinispanLockTest.java:243)
> at org.infinispan.lock.InfinispanLockTest$$Lambda$516/1905052434.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Locked ownable synchronizers: - <0x0000000084202468> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {noformat}
> I also suggest using {{AbstractInfinispanTest.fork()}} instead of an explicit {{ExecutorService}} in both tests, because without the test name in the thread name it's impossible to filter the test logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6100) L1 entries not always stored as L1InternalCacheEntry
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6100?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6100:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3957
> L1 entries not always stored as L1InternalCacheEntry
> ----------------------------------------------------
>
> Key: ISPN-6100
> URL: https://issues.jboss.org/browse/ISPN-6100
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> {{DistributedClusteringLogic.commitSingleEntry}} is using regular {{Metadata}} instead of {{L1Metadata}} when storing entries that are not owned by the local node. The entry will then be stored as a regular {{MortalCacheEntry}} instead of an {{L1InternalCacheEntry}}.
> In non-transactional mode, I believe this can only happen if the node was an owner at the time of entry wrapping. I'm not sure if the same applies in transactional caches.
> {{BaseDistFunctionalTest.assertOwnershipAndNonOwnership()}} assumes L1 entries are stored as {{L1InternalCacheEntries}}, so at the very least the mismatch results in random test failures in {{BaseDistFunctionalTest}} subclasses like {{ConcurrentJoinTest}}. It may result in stale data as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6103) LocalKeyAffinityTest.testFilteredRemoveServers random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6103?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6103:
-------------------------------
Status: Open (was: Pull Request Sent)
> LocalKeyAffinityTest.testFilteredRemoveServers random failures
> --------------------------------------------------------------
>
> Key: ISPN-6103
> URL: https://issues.jboss.org/browse/ISPN-6103
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> {noformat}
> 19:04:00,884 ERROR (testng-LocalKeyAffinityServiceTest:) [UnitTestTestNGListener] Test testFilteredRemoveServers(org.infinispan.affinity.impl.LocalKeyAffinityServiceTest) failed.
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:109) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:91) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:67) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:77) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:86) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:60) ~[test-classes/:?]
> at org.infinispan.affinity.impl.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:47) ~[test-classes/:?]
> {noformat}
> Counting the number of generated keys in the log, it seems to be correct, need better logging to determine if there are too few or too many keys in the queue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6102) Include the test name in the test thread names
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6102?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6102:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3956
> Include the test name in the test thread names
> ----------------------------------------------
>
> Key: ISPN-6102
> URL: https://issues.jboss.org/browse/ISPN-6102
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.Beta1
>
>
> Some random failures are much easier to reproduce when running the entire core test suite, which runs 15 tests in paralle, than when running a single test by itself. In such cases, it helps if we can filter the log messages that belong to the failing test, and the easiest way to do that is to include the test name in the thread name.
> Essentially, this means replacing {{ExecutorService}} instances with {{AbstractInfinispanTest.fork()}}, and where not possible instantiating the executor with {{AbstractInfinispanTest.getTestThreadFactory()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6102) Include the test name in the test thread names
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6102?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6102:
-------------------------------
Status: Open (was: New)
> Include the test name in the test thread names
> ----------------------------------------------
>
> Key: ISPN-6102
> URL: https://issues.jboss.org/browse/ISPN-6102
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.Beta1
>
>
> Some random failures are much easier to reproduce when running the entire core test suite, which runs 15 tests in paralle, than when running a single test by itself. In such cases, it helps if we can filter the log messages that belong to the failing test, and the easiest way to do that is to include the test name in the thread name.
> Essentially, this means replacing {{ExecutorService}} instances with {{AbstractInfinispanTest.fork()}}, and where not possible instantiating the executor with {{AbstractInfinispanTest.getTestThreadFactory()}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6103) LocalKeyAffinityTest.testFilteredRemoveServers random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6103?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6103:
-------------------------------
Status: Open (was: New)
> LocalKeyAffinityTest.testFilteredRemoveServers random failures
> --------------------------------------------------------------
>
> Key: ISPN-6103
> URL: https://issues.jboss.org/browse/ISPN-6103
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> {noformat}
> 19:04:00,884 ERROR (testng-LocalKeyAffinityServiceTest:) [UnitTestTestNGListener] Test testFilteredRemoveServers(org.infinispan.affinity.impl.LocalKeyAffinityServiceTest) failed.
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:109) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:91) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:67) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:77) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:86) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:60) ~[test-classes/:?]
> at org.infinispan.affinity.impl.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:47) ~[test-classes/:?]
> {noformat}
> Counting the number of generated keys in the log, it seems to be correct, need better logging to determine if there are too few or too many keys in the queue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6103) LocalKeyAffinityTest.testFilteredRemoveServers random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6103?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6103:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3956
> LocalKeyAffinityTest.testFilteredRemoveServers random failures
> --------------------------------------------------------------
>
> Key: ISPN-6103
> URL: https://issues.jboss.org/browse/ISPN-6103
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> {noformat}
> 19:04:00,884 ERROR (testng-LocalKeyAffinityServiceTest:) [UnitTestTestNGListener] Test testFilteredRemoveServers(org.infinispan.affinity.impl.LocalKeyAffinityServiceTest) failed.
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:109) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:91) ~[test-classes/:?]
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:67) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseKeyAffinityServiceTest.assertEventualFullCapacity(BaseKeyAffinityServiceTest.java:77) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.assertUnaffected(BaseFilterKeyAffinityServiceTest.java:86) ~[test-classes/:?]
> at org.infinispan.affinity.impl.BaseFilterKeyAffinityServiceTest.testRemoveServers(BaseFilterKeyAffinityServiceTest.java:60) ~[test-classes/:?]
> at org.infinispan.affinity.impl.LocalKeyAffinityServiceTest.testFilteredRemoveServers(LocalKeyAffinityServiceTest.java:47) ~[test-classes/:?]
> {noformat}
> Counting the number of generated keys in the log, it seems to be correct, need better logging to determine if there are too few or too many keys in the queue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (ISPN-6100) L1 entries not always stored as L1InternalCacheEntry
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6100?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6100:
-------------------------------
Status: Open (was: New)
> L1 entries not always stored as L1InternalCacheEntry
> ----------------------------------------------------
>
> Key: ISPN-6100
> URL: https://issues.jboss.org/browse/ISPN-6100
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.2.0.Beta1
>
>
> {{DistributedClusteringLogic.commitSingleEntry}} is using regular {{Metadata}} instead of {{L1Metadata}} when storing entries that are not owned by the local node. The entry will then be stored as a regular {{MortalCacheEntry}} instead of an {{L1InternalCacheEntry}}.
> In non-transactional mode, I believe this can only happen if the node was an owner at the time of entry wrapping. I'm not sure if the same applies in transactional caches.
> {{BaseDistFunctionalTest.assertOwnershipAndNonOwnership()}} assumes L1 entries are stored as {{L1InternalCacheEntries}}, so at the very least the mismatch results in random test failures in {{BaseDistFunctionalTest}} subclasses like {{ConcurrentJoinTest}}. It may result in stale data as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months