July 2014 - infinispan-issues - Jboss List Archives

[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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4524) ClusteredCacheWithAsyncDirTest.testCombinationOfFilters random failures

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4524?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-4524: -------------------------------------- Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha5) > ClusteredCacheWithAsyncDirTest.testCombinationOfFilters random failures > ------------------------------------------------------------------------ > > Key: ISPN-4524 > URL: https://issues.jboss.org/browse/ISPN-4524 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Query > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > The test fails in the CI build with TRACE enabled almost every time: > http://ci.infinispan.org/project.html?tab=testDetails&testNameId=64155977... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4542) Programmatic configuration doesn't have loaders() method

by Mikhail Dobrinin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4542?page=com.atlassian.jira.plugin.... ] Mikhail Dobrinin edited comment on ISPN-4542 at 7/17/14 7:42 PM: ----------------------------------------------------------------- comment edited was (Author: mdobrinin): Actually there does appear to be a way to do it programmatically, but here is the syntax: {code} Configuration config = new ConfigurationBuilder() .persistence() .addStore(Store.class) .loaderClass(MockLoader.class.getName()) .build(); {code} > Programmatic configuration doesn't have loaders() method > -------------------------------------------------------- > > Key: ISPN-4542 > URL: https://issues.jboss.org/browse/ISPN-4542 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Mikhail Dobrinin > Assignee: Mircea Markus > Priority: Minor > > The ConfigurationBuilder class does not actually have a {{loaders}} method. However, the documentation mentions it in a few places such as here -- http://infinispan.org/docs/6.0.x/user_guide/user_guide.html if you search for {{loaders()}} on the page. Also it's not clear to a user if it's possible to configure a custom cache loader programmatically because of this. I'm guessing it's not actually possible. That makes it hard to write tests with a mocked cacheloader. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4542) Programmatic configuration doesn't have loaders() method

by Mikhail Dobrinin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4542?page=com.atlassian.jira.plugin.... ] Mikhail Dobrinin commented on ISPN-4542: ---------------------------------------- Actually there does appear to be a way to do it programmatically, but here is the syntax: {code} Configuration config = new ConfigurationBuilder() .persistence() .addStore(Store.class) .loaderClass(MockLoader.class.getName()) .build(); {code} > Programmatic configuration doesn't have loaders() method > -------------------------------------------------------- > > Key: ISPN-4542 > URL: https://issues.jboss.org/browse/ISPN-4542 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Mikhail Dobrinin > Assignee: Mircea Markus > Priority: Minor > > The ConfigurationBuilder class does not actually have a {{loaders}} method. However, the documentation mentions it in a few places such as here -- http://infinispan.org/docs/6.0.x/user_guide/user_guide.html if you search for {{loaders()}} on the page. Also it's not clear to a user if it's possible to configure a custom cache loader programmatically because of this. I'm guessing it's not actually possible. That makes it hard to write tests with a mocked cacheloader. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4446) removeCache fails for caches with a SingleFileStore

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4446?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4446: ----------------------------------- Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.CR1) > 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.Alpha5, 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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4446) removeCache fails for caches with a SingleFileStore

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4446?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-4446: ---------------------------------------- I've got a fix for this, but not sure if I'll be approved since it uses thread locals. See the PR link for comments on it. > 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.CR1, 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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4446) removeCache fails for caches with a SingleFileStore

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4446?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4446: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2730 > 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.CR1, 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)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4541) release.py script fails due to as-modules split

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4541?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4541: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2729 > release.py script fails due to as-modules split > ----------------------------------------------- > > Key: ISPN-4541 > URL: https://issues.jboss.org/browse/ISPN-4541 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build process > Affects Versions: 7.0.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 7.0.0.Alpha5 > > > Due to split in as-modules to client and embedded the release script fails. Here is the failure https://gist.github.com/vblagoje/47231cc19dc4ed62475f -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4541) release.py script fails due to as-modules split

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4541?page=com.atlassian.jira.plugin.... ] William Burns resolved ISPN-4541. --------------------------------- Resolution: Done > release.py script fails due to as-modules split > ----------------------------------------------- > > Key: ISPN-4541 > URL: https://issues.jboss.org/browse/ISPN-4541 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build process > Affects Versions: 7.0.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 7.0.0.Alpha5 > > > Due to split in as-modules to client and embedded the release script fails. Here is the failure https://gist.github.com/vblagoje/47231cc19dc4ed62475f -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4542) Programmatic configuration doesn't have loaders() method

by Mikhail Dobrinin (JIRA)

Mikhail Dobrinin created ISPN-4542: -------------------------------------- Summary: Programmatic configuration doesn't have loaders() method Key: ISPN-4542 URL: https://issues.jboss.org/browse/ISPN-4542 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Mikhail Dobrinin Assignee: Mircea Markus Priority: Minor The ConfigurationBuilder class does not actually have a {{loaders}} method. However, the documentation mentions it in a few places such as here -- http://infinispan.org/docs/6.0.x/user_guide/user_guide.html if you search for {{loaders()}} on the page. Also it's not clear to a user if it's possible to configure a custom cache loader programmatically because of this. I'm guessing it's not actually possible. That makes it hard to write tests with a mocked cacheloader. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014