[JBoss JIRA] (ISPN-2804) Memory Leak: TransactionTable never cleans up complete transactions
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2804?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2804:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated. Thanks!
> Memory Leak: TransactionTable never cleans up complete transactions
> -------------------------------------------------------------------
>
> Key: ISPN-2804
> URL: https://issues.jboss.org/browse/ISPN-2804
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.0.Final
> Reporter: Erik Salter
> Assignee: Erik Salter
> Priority: Blocker
> Fix For: 5.2.1, 5.3.0.Alpha1
>
>
> When a transaction commits, we mark it as completed in markCompletedTransaction(). The issue is this map is never cleaned up -- there is no call to cleanupCompletedTransactions().
> (Was this supposed to replace the StaleTransactionCleanupService?)
> So the transaction (and address and UUID object) leak for every transaction, until the node OOMs.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2441) Some core interceptors trigger custom interceptor error message
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2441?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2441:
--------------------------------
Assignee: Manik Surtani (was: Mircea Markus)
> Some core interceptors trigger custom interceptor error message
> ---------------------------------------------------------------
>
> Key: ISPN-2441
> URL: https://issues.jboss.org/browse/ISPN-2441
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Manik Surtani
> Fix For: 5.2.1, 5.3.0.Final
>
>
> I'm not sure if this is really a problem or if it's just a superfluous error message, but I'm seeing about 6000 of these during a typical test suite run:
> {noformat}
> ISPN000173: Custom interceptor org.infinispan.interceptors.ActivationInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods.
> ISPN000173: Custom interceptor org.infinispan.interceptors.CacheMgmtInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods.
> ISPN000173: Custom interceptor org.infinispan.interceptors.DistCacheStoreInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods.
> ISPN000173: Custom interceptor org.infinispan.interceptors.InvalidationInterceptor has used @Inject, @Start or @Stop. These methods will not be processed. Please extend org.infinispan.interceptors.base.BaseCustomInterceptor instead, and your custom interceptor will have access to a cache and cacheManager. Override stop() and start() for lifecycle methods.
> {noformat}
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-201:
-------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 5.3.0.Final)
> make JDBC cache store use DB transactions for commit/rollback
> -------------------------------------------------------------
>
> Key: ISPN-201
> URL: https://issues.jboss.org/browse/ISPN-201
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Tristan Tarrant
> Labels: modshape
> Fix For: 6.0.0.Beta1
>
>
> current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-201:
-------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.Beta1)
> make JDBC cache store use DB transactions for commit/rollback
> -------------------------------------------------------------
>
> Key: ISPN-201
> URL: https://issues.jboss.org/browse/ISPN-201
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Mircea Markus
> Assignee: Tristan Tarrant
> Labels: modshape
> Fix For: 6.0.0.Final
>
>
> current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2589) NPE in InvalidateL1Command
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2589?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2589:
-------------------------------------
On cache leave (shutdown) the node _sometimes_ receives the new CH in which all its data segments are removed and it will (needlessly) attempt to discard that data (or move it to L1 if enabled) but fails due to NPE because some cache components are already shut down (DistributionManager). This affects both DIST and REPL caches because the state transfer code is common but it was never expected that segments are ever removed in a REPL cache (can happen only during shutdown). This last CH update is irrelevant and is not always received, thus not always reproducible and failing to process it is just logged as a warning. The best way to fix this is to ensure LocalTopologyManager does not deliver CH updates after leave.
> NPE in InvalidateL1Command
> --------------------------
>
> Key: ISPN-2589
> URL: https://issues.jboss.org/browse/ISPN-2589
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Thomas Fromm
> Assignee: Adrian Nistor
> Fix For: 5.2.1, 5.3.0.Final
>
> Attachments: standalone_node0001.xml
>
>
> The used cache is an REPL_SYNC one w/o L1 and Optimistic TX.
> Can't provide unit test, just saw it in my logs.
> WARN 05.12.12 20:08:22,746 [OOB-173,IBIS-2147] CacheTopologyControlCommand ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MODULE_PROPERTIES_VERSION, type=CH_UPDATE, sender=IBIS-57850, joinInfo=null, topologyId=14, currentCH=ReplicatedConsistentHash{members=[IBIS-57850, IBIS-15651, IBIS-14611, IBIS-7942, IBIS-4256, IBIS-25472, IBIS-32523]}, pendingCH=null, throwable=null, viewId=8}
> java.lang.NullPointerException
> at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
> at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:110)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitInvalidateCommand(CacheLoaderInterceptor.java:127)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:256)
> at org.infinispan.interceptors.TxInterceptor.visitInvalidateCommand(TxInterceptor.java:224)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:172)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:592)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:239)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:117)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FC.up(FC.java:479)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2687) DistributedExecutorWithTopologyAwareNodesTest.testRunnableExecution fails randomly
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2687?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2687:
--------------------------------
Assignee: Mircea Markus (was: Vladimir Blagojevic)
> DistributedExecutorWithTopologyAwareNodesTest.testRunnableExecution fails randomly
> ----------------------------------------------------------------------------------
>
> Key: ISPN-2687
> URL: https://issues.jboss.org/browse/ISPN-2687
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Execution and Map/Reduce, Test Suite
> Affects Versions: 5.2.0.Beta6
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Fix For: 5.2.1, 5.3.0.Final
>
>
> The test assumes that a task is executed in under 100ms, which is not necessarily true when running the parallel test suite:
> {noformat}
> java.lang.AssertionError
> at org.infinispan.distexec.LocalDistributedExecutorTest.testRunnableExecution(LocalDistributedExecutorTest.java:139)
> {noformat}
> It should probably use {{AbstractInfinispanTest.eventually()}} instead of sleeping for a fixed amount of time.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2504?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2504:
--------------------------------
Assignee: Pedro Ruivo (was: Mircea Markus)
> WriteSkew check fails for entries which are inserted first time
> ---------------------------------------------------------------
>
> Key: ISPN-2504
> URL: https://issues.jboss.org/browse/ISPN-2504
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.0.Beta3
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Fix For: 5.2.1, 5.3.0.Final
>
>
> If optimistic locking and write skew check are configured and there are two concurrent transactions performing
> {code}
> read(key) -> null
> write(key, value)
> {code}
> one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
> {code}
> EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
> if (versionSeen != null) entry.setVersion(versionSeen);
> {code}
> As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.
--
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
13 years, 2 months