[JBoss JIRA] (ISPN-4027) TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4027?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4027:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1152942|https://bugzilla.redhat.com/show_bug.cgi?id=1152942] from VERIFIED to CLOSED
> TransactionTable.start() initialize the TxCleanupService thread pool even when the cache is NON_TRANSACTIONAL
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4027
> URL: https://issues.jboss.org/browse/ISPN-4027
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.1.Final
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Takayoshi Kimura
> Labels: 630
> Fix For: 7.0.0.CR2
>
>
> In the {{TransactionTable.start()}} each cache creates a thread pool and a job is scheduled to clean up completed transactions.
> {code:java}
> private void start() {
> ...
> totalOrder = configuration.transaction().transactionProtocol().isTotalOrder();
> if (!totalOrder) {
> // Periodically run a task to cleanup the transaction table from completed transactions.
> ThreadFactory tf = new ThreadFactory() {
> @Override
> public Thread newThread(Runnable r) {
> String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
> Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
> th.setDaemon(true);
> return th;
> }
> };
> executorService = Executors.newSingleThreadScheduledExecutor(tf);
> long interval = configuration.transaction().reaperWakeUpInterval();
> executorService.scheduleAtFixedRate(new Runnable() {
> @Override
> public void run() {
> cleanupCompletedTransactions();
> }
> }, interval, interval, TimeUnit.MILLISECONDS);
> }
> }
> {code}
> As you can see in the code, even is the cache is {{NON_TRANSACTIONAL}} the job is scheduled, consuming resources to do nothing (the {{completedTransactions}} map is always empty)
> Maybe I'm missing something, but our application profiling is showing us that these threads do nothing but they are consuming precious resources because we have more than 1000 {{NON_TRANSACTIONAL}} caches.
> (i) This can be considered when solving ISPN-3702 too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5142) Cross site state transfer - retry mechanism not working correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5142?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5142:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1181129|https://bugzilla.redhat.com/show_bug.cgi?id=1181129] from VERIFIED to CLOSED
> Cross site state transfer - retry mechanism not working correctly
> -----------------------------------------------------------------
>
> Key: ISPN-5142
> URL: https://issues.jboss.org/browse/ISPN-5142
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Beta1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.CR2
>
>
> 2 sites - main (2 nodes), backup (3 nodes)
> Scenario:
> 1. take consumer site offline
> 2. write data into producer site
> 3. invoke push(backup) operation
> 4. write data into consumer site (such that key set overlaps with the one used in step#2)
> Configuration:
> - sync backup, 2pc
> - Pessimistic TX, multiple operations in a single TX (e.g. 20)
> Consumer site logs indicate occuring lock acquisition problems, leading to chunk not being applied. In that case, the chunk should be re-sent, however, the retry mechanism does not wait for the reply from the retry.
> pruivo's note: retry mechanism can end up in an infinite loop
> 11:25:53,549 WARN [org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl] (remote-thread-3) ISPN000291: Unable to apply X-Site state chunk.
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [3 seconds] on key [key_0000000000002652] for requestor [GlobalTransaction:<localhost-17627>:25:local]! Lock held by [GlobalTransaction:<localhost-11416>:43:remote]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lockAndRegisterBackupLock(PessimisticLockingInterceptor.java:304)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:101)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:241)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:183)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:119)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:148)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:134)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:104)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:34)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.applyStateInTransaction(XSiteStateConsumerImpl.java:111)
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.applyState(XSiteStateConsumerImpl.java:92)
> at org.infinispan.xsite.statetransfer.XSiteStatePushCommand.perform(XSiteStatePushCommand.java:50)
> at org.infinispan.remoting.LocalInvocation.call(LocalInvocation.java:43)
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferState(BackupReceiverImpl.java:140)
> at org.infinispan.xsite.statetransfer.XSiteStatePushCommand.performInLocalSite(XSiteStatePushCommand.java:32)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4746) NPE when preloading cache with DeltaAware values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4746?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4746:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from VERIFIED to CLOSED
> NPE when preloading cache with DeltaAware values
> ------------------------------------------------
>
> Key: ISPN-4746
> URL: https://issues.jboss.org/browse/ISPN-4746
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final, 7.0.0.Beta2
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.0.0.CR1, 7.0.0.Final
>
>
> {code:java}
> public class DeltaAwarePreloadTest extends MultipleCacheManagersTest {
> private static final int CLUSTER_SIZE = 1;
> @Override
> protected void createCacheManagers() throws Throwable {
> ConfigurationBuilder c = getDefaultClusteredCacheConfig(CacheMode.DIST_SYNC, false);
> c.persistence().addStore(new DummyInMemoryStoreConfigurationBuilder(c.persistence()).storeName(getClass().getSimpleName())).preload(true);
> createCluster(c, CLUSTER_SIZE);
> waitForClusterToForm();
> }
> @Test
> public void testPreloadOnStart() throws PersistenceException {
> Cache<Object, Object> cache = caches().get(0);
> cache.put(1, new TestDeltaAware());
> cache.stop();
> cache.start();
> }
> }
> {code}
> During preload, the {{NonTxDistributionInterceptor}} decides that is requires values from previous owners and tries to check if the local node is the primary owner. At this point, the WriteCH is null since no topology was ever updated. Here's the stacktrace:
> {code}
> Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:620)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:228)
> at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:220)
> 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:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.distribution.impl.DistributionManagerImpl.getWriteConsistentHash(DistributionManagerImpl.java:115)
> at org.infinispan.distribution.impl.DistributionManagerImpl.getConsistentHash(DistributionManagerImpl.java:105)
> at org.infinispan.distribution.impl.DistributionManagerImpl.getPrimaryLocation(DistributionManagerImpl.java:95)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.localNodeIsPrimaryOwner(ClusteringDependentLogic.java:395)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.remoteGetBeforeWrite(NonTxDistributionInterceptor.java:131)
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:195)
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitPutKeyValueCommand(NonTxDistributionInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.DistCacheWriterInterceptor.visitPutKeyValueCommand(DistCacheWriterInterceptor.java:72)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:113)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:376)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:464)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5001) NPE on preload with tx caches containing DeltaAware values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5001?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5001:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1166028|https://bugzilla.redhat.com/show_bug.cgi?id=1166028] from VERIFIED to CLOSED
> NPE on preload with tx caches containing DeltaAware values
> ----------------------------------------------------------
>
> Key: ISPN-5001
> URL: https://issues.jboss.org/browse/ISPN-5001
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 7.1.0.Alpha1
>
>
> A similar bug was fixed for non-tx caches on ISPN-4746
> To reproduce the issue, change the {{DeltaAwarePreloadTest}} to use transactional cache.
> Error:
> {code}
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.preload() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:813)
> at org.infinispan.distribution.DeltaAwarePreloadTest.testPreloadOnStart(DeltaAwarePreloadTest.java:38)
> 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:606)
> 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.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125)
> 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:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: org.infinispan.persistence.spi.PersistenceException: Unable to preload!
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preloadKey(PersistenceManagerImpl.java:633)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.access$000(PersistenceManagerImpl.java:70)
> at org.infinispan.persistence.manager.PersistenceManagerImpl$1.processEntry(PersistenceManagerImpl.java:232)
> at org.infinispan.persistence.dummy.DummyInMemoryStore.process(DummyInMemoryStore.java:165)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.preload(PersistenceManagerImpl.java:224)
> 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:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.distribution.impl.DistributionManagerImpl.getReadConsistentHash(DistributionManagerImpl.java:110)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:319)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGetBeforeWrite(TxDistributionInterceptor.java:311)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:269)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitPutKeyValueCommand(TxDistributionInterceptor.java:105)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4949:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161214|https://bugzilla.redhat.com/show_bug.cgi?id=1161214] from VERIFIED to CLOSED
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.1.0.Alpha1, 7.0.3.Final
>
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5030) NPE during node rebalance after a leave
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5030?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5030:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161214|https://bugzilla.redhat.com/show_bug.cgi?id=1161214] from VERIFIED to CLOSED
> NPE during node rebalance after a leave
> ---------------------------------------
>
> Key: ISPN-5030
> URL: https://issues.jboss.org/browse/ISPN-5030
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.0.Alpha1
> Reporter: Sanne Grinovero
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 7.0.3.Final, 7.1.0.Beta1
>
>
> I'm seeing stacktraces dumped to standard out during the normal test run of the infinispan-core module:
> {noformat}
> 2014-11-28 21:39:52,652 WARN [CacheTopologyControlCommand] (remote-thread-DistributedEntryRetrieverTest-NodeA-p610-t6) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=org.infinispan.iteration.DistributedEntryRetrieverTest, type=LEAVE, sender=DistributedEntryRetrieverTest-NodeC-12939, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=2}
> java.lang.NullPointerException
> at org.infinispan.topology.ClusterCacheStatus.updateRebalanceMembers(ClusterCacheStatus.java:307)
> at org.infinispan.topology.ClusterCacheStatus.doLeave(ClusterCacheStatus.java:578)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleLeave(ClusterTopologyManagerImpl.java:148)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:164)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:278)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is the unmodified testsuite, in current master {{33c5f85}}. It doesn't seem to cause actual test failures.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months