[JBoss JIRA] (ISPN-4446) removeCache fails for caches with a SingleFileStore
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4446?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4446:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> removeCache fails for caches with a SingleFileStore
> ---------------------------------------------------
>
> Key: ISPN-4446
> URL: https://issues.jboss.org/browse/ISPN-4446
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.2.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> If DefaultCacheManager.isRunning("foo") returns true, and "foo" has an associated SingleFileStore, calling DefaultCacheManager.removeCache("foo") tosses an NPE and isRunning("foo") continues to return true, even though the cache is in a TERMINATED state. I can avoid the NPE by stopping the cache before calling removeCache, but isRunning will still incorrectly return true.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4512) CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4512?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4512:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> CacheManagerTest.testCacheManagerRestartReusingConfigurations random failures
> -----------------------------------------------------------------------------
>
> Key: ISPN-4512
> URL: https://issues.jboss.org/browse/ISPN-4512
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
> Attachments: CacheManagerTest_t_ISPN-4154_failing_elasticity_test_20140707.log.gz
>
>
> When a new cache manager is started with the same configuration, it uses the JGroupsTransport instance. In some rare cases, the JGroupsTransport keeps using the old marshaller, which doesn't work, and the cache fails to start:
> {noformat}
> 23:54:08,203 TRACE (testng-CacheManagerTest:___defaultcache) [JGroupsTransport] dests=[NodeB-24139], command=CacheTopologyControlCommand{cache=___defaultcache, type=JOIN, sender=NodeA-33664, joinInfo=CacheJoinInfo{consistentHashFactory=org.infinispan.distribution.ch.impl.ReplicatedConsistentHashFactory@b8c8791, hashFunction=MurmurHash3, numSegments=60, numOwners=2, timeout=240000, totalOrder=false, distributed=false}, topologyId=0, currentCH=null, pendingCH=null, throwable=null, viewId=3}, mode=SYNCHRONOUS, timeout=240000
> 23:54:08,207 DEBUG (testng-CacheManagerTest:___defaultcache) [VersionAwareMarshaller] Object is not serializable
> java.io.NotSerializableException: org.infinispan.topology.CacheTopologyControlCommand
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:890)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:73)
> at org.infinispan.marshall.core.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:77)
> at org.infinispan.commons.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:41)
> at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:85)
> at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:23)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:335)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:352)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:526)
> at org.infinispan.topology.LocalTopologyManagerImpl.executeOnCoordinator(LocalTopologyManagerImpl.java:290)
> at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:100)
> at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:104)
> {noformat}
> The only test that does this is CacheManagerTest.testCacheManagerRestartReusingConfigurations.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4504) Topology id is not properly set on ClusteredGetCommands
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4504?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4504:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> Topology id is not properly set on ClusteredGetCommands
> -------------------------------------------------------
>
> Key: ISPN-4504
> URL: https://issues.jboss.org/browse/ISPN-4504
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> Because the topology id is not properly set on ClusteredGetCommands, they don't wait for the sender's topology to be installed on the target.
> I have tried to fix this while implementing a fix for ISPN-4503. My solution caused 2 failures in RemoteGetDuringStateTransferTest, scenarios 5 and 7::
> | sc | currentTopologyId | currentTopologyId + 1 (rebalance) | currentTopologyId + 2 (finish) |
> | 5 | 0:remoteGet | 2:sendReply | 0:receiveReply, 1:sendReply |
> | 7 | | 0:remoteGet, 2: sendReply | 0:receiveReply, 1:sendReply |
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4503) Commands with topology id 0 are not properly ignored on joiners
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4503?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4503:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> Commands with topology id 0 are not properly ignored on joiners
> ---------------------------------------------------------------
>
> Key: ISPN-4503
> URL: https://issues.jboss.org/browse/ISPN-4503
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> InboundInvocationHandlerImpl is supposed to ignore commands sent with a topology id smaller than the first topology id in which the local node was a member. But there is a loophole when the command was sent with topology id 0.
> This is visible in StateTransferFunctionalTest, where the writing thread keeps the cpu busy and can delay the 2nd node joining for a long time (especially when run on a single core with {{taskset -c 0}}). For some reason, the PrepareCommands are sent only to the local node, while the TxCompletionNotificationCommands are sent to the entire cluster ({{null}}). When the 2nd node manages to join, it receives a lot of TxCompletionNotificationCommands and processing them delays the processing of the rebalance commands. Since the writes eventually block waiting for the new topology to be installed on the joiner, the delayed rebalance commands cause the write to time out.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4521) ReplicationQueueTest.testReplicationQueueMultipleThreads random failures
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4521?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4521:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> ReplicationQueueTest.testReplicationQueueMultipleThreads random failures
> ------------------------------------------------------------------------
>
> Key: ISPN-4521
> URL: https://issues.jboss.org/browse/ISPN-4521
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, Test Suite - Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Beta1
>
>
> Either the test didn't manage to fill the replication queue in 3 seconds, or there are some extra entries from the previous test...
> {noformat}
> java.lang.AssertionError
> at org.infinispan.replication.ReplicationQueueTest.testReplicationQueueMultipleThreads(ReplicationQueueTest.java:194)
> {noformat}
> The test should be changed to use proper assertions and prevent interference between test methods.
> Perhaps we should also revisit the changes I made for ISPN-1123, they make the last lines of {[testReplicationQueueMultipleThreads}} look superfluous.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4519) Prepare should be broadcasted to entire cluster in replicated mode
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4519?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4519:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> Prepare should be broadcasted to entire cluster in replicated mode
> ------------------------------------------------------------------
>
> Key: ISPN-4519
> URL: https://issues.jboss.org/browse/ISPN-4519
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> TxDistributionInterceptor.visitPrepareCommand explicitly checks if the {{recipients}} collection is {{null}} and replaces it with the list of cache members. This was done for total order, but TOA now supports sending messages to {{null}}, so there is no reason to handle this in our code.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4517) RollbackCommands should ignore leavers
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4517?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4517:
--------------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha5)
> RollbackCommands should ignore leavers
> --------------------------------------
>
> Key: ISPN-4517
> URL: https://issues.jboss.org/browse/ISPN-4517
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
>
> When one of the targets of a PrepareCommand leaves, the originator receives a SuspectException and tries to roll back the transaction. However, the RollbackCommand can also fail with with a SuspectException if:
> * syncRollbackPhase = true (the default, since ISPN-4137)
> * The cache topology hasn't been updated to exclude the leaver yet (maybe because it was the old coordinator that left)
> In that case, we could throw a SuspectException in JGroupsTransport.invokeRemotely without sending the RollbackCommand to the other owner:
> {noformat}
> 23:34:01,219 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (PrivateLogChecker-4) ISPN000136: Execution error
> org.infinispan.remoting.transport.jgroups.SuspectException: One or more nodes have left the cluster while replicating command RollbackCommand {gtx=GlobalTransaction:<edg-perf08-52473>:1077:local, cacheName='testCache', topologyId=8}
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:486)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281)
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRollbackCommand(TxDistributionInterceptor.java:223)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitRollbackCommand(AbstractTxLockingInterceptor.java:51)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.NotificationInterceptor.visitRollbackCommand(NotificationInterceptor.java:50)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.visitRollbackCommand(TxInterceptor.java:207)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitRollbackCommand(TransactionSynchronizerInterceptor.java:66)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:222)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:153)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitRollbackCommand(StateTransferInterceptor.java:91)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> 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.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitRollbackCommand(AbstractVisitor.java:101)
> at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.transaction.TransactionCoordinator.rollbackInternal(TransactionCoordinator.java:237)
> at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:172)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1436)
> at org.infinispan.CacheImpl.putInternal(CacheImpl.java:904)
> at org.infinispan.CacheImpl.put(CacheImpl.java:896)
> at org.infinispan.CacheImpl.put(CacheImpl.java:1471)
> at org.infinispan.CacheImpl.put(CacheImpl.java:231)
> at org.radargun.cachewrappers.InfinispanBasicOperations.put(InfinispanBasicOperations.java:25)
> at org.radargun.cachewrappers.Infinispan51BasicOperations.put(Infinispan51BasicOperations.java:31)
> at org.radargun.cachewrappers.Infinispan52BasicOperations.put(Infinispan52BasicOperations.java:16)
> at org.radargun.cachewrappers.InfinispanWrapper.put(InfinispanWrapper.java:185)
> at org.radargun.stressors.LogChecker.run(LogChecker.java:106)
> {noformat}
> The RollbackCommand should have the SYNCHRONOUS_IGNORE_LEAVERS ResponseMode, so that the owner still alive receives the the command. Otherwise, that stale transaction will never be completed.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months