[JBoss JIRA] (ISPN-2395) Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2395?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2395:
--------------------------------
Priority: Minor (was: Major)
> Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2395
> URL: https://issues.jboss.org/browse/ISPN-2395
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.5.FINAL, 5.1.6.FINAL, 5.1.7.Final, 5.2.0.Beta1
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Priority: Minor
> Attachments: TestLocking.java
>
>
> In ISPN 5.0, you provided a workaround allowing us to sort the keys ourself in order to prevent deadlocks even in case we enable the lock striping (more details here ISPN-993), thanks to this workaround we could write a simple key comparator (that works with lock striping enabled or not) as next:
> {code}
> public int compare(Object k1, Object k2) {
> LockManager lm = cache.getLockManager();
> int result = lm.getLockId(key1) - lm.getLockId(k2);
> }
> {code}
> Starting from ISPN 5.1 (ISPN-1132), the keys are sorted automatically by ISPN however unfortunately what has been done is incompatible with lock striping, indeed the keys are sorted regardless the lock distribution which is a mistake since we actually expect the keys to be sorted according to the corresponding locks and not to the keys themselves otherwise deadlock can still occur.
> As attached file, you will find a test case that shows the issue.
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-2367) ReadCommitted does not work in distributed mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2367?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2367:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
> ReadCommitted does not work in distributed mode
> -----------------------------------------------
>
> Key: ISPN-2367
> URL: https://issues.jboss.org/browse/ISPN-2367
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.7.Final
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Attachments: ReadCommittedDistributedTest.java
>
>
> ReadCommitted isolation level doesn't work as expected in distributed mode:
> - tx1@Node1 reads (k1,v1) which is owned by Node2. At this point it keeps a cached copy of the entry locally
> - tx2@Node3 writes (k1,v2) and commits
> - tx1@Node1 reads k1 again and it gets the value "v1" - wrong!
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-2395) Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2395?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2395:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
> Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2395
> URL: https://issues.jboss.org/browse/ISPN-2395
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.5.FINAL, 5.1.6.FINAL, 5.1.7.Final, 5.2.0.Beta1
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Attachments: TestLocking.java
>
>
> In ISPN 5.0, you provided a workaround allowing us to sort the keys ourself in order to prevent deadlocks even in case we enable the lock striping (more details here ISPN-993), thanks to this workaround we could write a simple key comparator (that works with lock striping enabled or not) as next:
> {code}
> public int compare(Object k1, Object k2) {
> LockManager lm = cache.getLockManager();
> int result = lm.getLockId(key1) - lm.getLockId(k2);
> }
> {code}
> Starting from ISPN 5.1 (ISPN-1132), the keys are sorted automatically by ISPN however unfortunately what has been done is incompatible with lock striping, indeed the keys are sorted regardless the lock distribution which is a mistake since we actually expect the keys to be sorted according to the corresponding locks and not to the keys themselves otherwise deadlock can still occur.
> As attached file, you will find a test case that shows the issue.
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-2395) Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2395?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2395:
-------------------------------------
you can disable lock stripping and this will work. A solution for this would be to allow the use provide their own lock comparator used for sorting the locks. Not a very high prio IMO, but let's keep the JIRA around in case it gets some traction.
> Key sorting done by the OptimisticLockingInterceptor is incompatible with the lock striping
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2395
> URL: https://issues.jboss.org/browse/ISPN-2395
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.5.FINAL, 5.1.6.FINAL, 5.1.7.Final, 5.2.0.Beta1
> Reporter: Nicolas Filotto
> Assignee: Mircea Markus
> Attachments: TestLocking.java
>
>
> In ISPN 5.0, you provided a workaround allowing us to sort the keys ourself in order to prevent deadlocks even in case we enable the lock striping (more details here ISPN-993), thanks to this workaround we could write a simple key comparator (that works with lock striping enabled or not) as next:
> {code}
> public int compare(Object k1, Object k2) {
> LockManager lm = cache.getLockManager();
> int result = lm.getLockId(key1) - lm.getLockId(k2);
> }
> {code}
> Starting from ISPN 5.1 (ISPN-1132), the keys are sorted automatically by ISPN however unfortunately what has been done is incompatible with lock striping, indeed the keys are sorted regardless the lock distribution which is a mistake since we actually expect the keys to be sorted according to the corresponding locks and not to the keys themselves otherwise deadlock can still occur.
> As attached file, you will find a test case that shows the issue.
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-2489) infinispan-core stores resources in default package, preventing OSGI export
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2489?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2489:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
> infinispan-core stores resources in default package, preventing OSGI export
> ---------------------------------------------------------------------------
>
> Key: ISPN-2489
> URL: https://issues.jboss.org/browse/ISPN-2489
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 5.1.6.FINAL, 5.2.0.Beta3
> Reporter: Vitalii Tymchyshyn
> Assignee: Mircea Markus
>
> Currently infinispan stores resources (e.g. infinispan-core-component-metadata.dat) in the default package. This makes this resources private to infinispan-core OSGI bundle as default package can't be exported
> So, first of all it does not start by default when cache manager is created from another bundle. If configuration is created explicitly passing infinispan-core classloader, it can start, but no additional components can be used (e.g. loaders from another bundles).
> I can see next possible options to handle this:
> 1) Move resources to the package
> 2) Use multiple classloaders to read resources (as it's done for classes)
> 3) Use exact classloader, e.g. use fixed infinispan-core classloader to get infinispan-core-component-metadata.dat. Dunno if this would work for all resources, like jgroups configuration files.
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-2617) Intermittent failure of NodeMoveAPITest.testConcurrency
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2617?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2617:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Intermittent failure of NodeMoveAPITest.testConcurrency
> -------------------------------------------------------
>
> Key: ISPN-2617
> URL: https://issues.jboss.org/browse/ISPN-2617
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite, Tree API
> Affects Versions: 5.1.8.Final
> Reporter: Jitka Kudrnacova
> Assignee: Dan Berindei
> Fix For: 6.0.0.Alpha1
>
>
> The test NodeMoveAPITest.testConcurrency fails intermittently across platforms and JDKs.
> This is the output of TS on RHEL6_x86_64, Oracle JDK 6.
> Stacktrace:
> {code}
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}
> Output:
> {code}
> 2012-12-05 10:21:34,463 FATAL [NodeMoveAPITest] (testng-NodeMoveAPITest) Tree:
> + / {}
> + b/ {}
> + x/ {}
> + a/ {}
> + e/ {}
> + c/ {}
> + x/ {}
> + y/ {}
> + d/ {}
> 2012-12-05 10:21:34,464 ERROR [UnitTestTestNGListener] (testng-NodeMoveAPITest) Method testConcurrency(org.infinispan.api.tree.NodeMoveAPITest) threw an exception
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> [testng-NodeMoveAPITest] Test testConcurrency(org.infinispan.api.tree.NodeMoveAPITest) failed.
> 2012-12-05 10:21:34,466 ERROR [UnitTestTestNGListener] (testng-NodeMoveAPITest) Test failed testConcurrency(org.infinispan.api.tree.NodeMoveAPITest)
> java.lang.AssertionError: Should have only found x once
> at org.testng.AssertJUnit.fail(AssertJUnit.java:57)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:39)
> at org.infinispan.api.tree.NodeMoveAPITest.testConcurrency(NodeMoveAPITest.java:405)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:673)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1147)
> at org.testng.TestRunner.privateRun(TestRunner.java:749)
> at org.testng.TestRunner.run(TestRunner.java:600)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:317)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:34)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351)
> at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {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
11 years, 6 months
[JBoss JIRA] (ISPN-3149) Unexpected reporting of no live owners
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3149?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3149:
-------------------------------------
Reducing priority as this is just logging noise (see Micha's last comment).
> Unexpected reporting of no live owners
> --------------------------------------
>
> Key: ISPN-3149
> URL: https://issues.jboss.org/browse/ISPN-3149
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Beta2
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
>
> Running a four node test with infinispan-server 5.3.0-SNAPSHOT
> produces following errors:
> {code}
> 08:46:22,962 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Starting StateTransferManager of cache testCache on node node01/default
> 08:46:22,969 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Installing new cache topology CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null} on cache testCache
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Received new topology for cache testCache, isRebalance = false, isMember = true, topology = CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null}
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (MSC service thread 1-3) Signalling topology 0 is installed
> 08:46:22,973 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) On cache testCache we have: added segments: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37]
> 08:46:22,974 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37] of cache testCache
> 08:46:22,974 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 0 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,975 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 1 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 2 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 3 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 4 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 5 of cache testCache. Current owners are:
> {code}
> all logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> configs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> infinispan-server build info:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
--
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
11 years, 6 months
[JBoss JIRA] (ISPN-3149) Unexpected reporting of no live owners
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3149?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3149:
--------------------------------
Priority: Minor (was: Major)
> Unexpected reporting of no live owners
> --------------------------------------
>
> Key: ISPN-3149
> URL: https://issues.jboss.org/browse/ISPN-3149
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Beta2
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Priority: Minor
>
> Running a four node test with infinispan-server 5.3.0-SNAPSHOT
> produces following errors:
> {code}
> 08:46:22,962 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Starting StateTransferManager of cache testCache on node node01/default
> 08:46:22,969 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Installing new cache topology CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null} on cache testCache
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Received new topology for cache testCache, isRebalance = false, isMember = true, topology = CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null}
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (MSC service thread 1-3) Signalling topology 0 is installed
> 08:46:22,973 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) On cache testCache we have: added segments: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37]
> 08:46:22,974 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37] of cache testCache
> 08:46:22,974 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 0 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,975 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 1 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 2 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 3 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 4 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 5 of cache testCache. Current owners are:
> {code}
> all logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> configs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> infinispan-server build info:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
--
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
11 years, 6 months