[infinispan-issues] [JBoss JIRA] (ISPN-1595) Implicit transactions not being cleared from transaction table

[ https://issues.jboss.org/browse/ISPN-1595?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-1595 at 12/20/11 5:19 AM: ------------------------------------------------------------------ TxCompletionNotificationCommand is used to remove remote transactions and this is sent asynchronously. However, sometimes when the test is executed (org.infinispan.lock.APITest.testSilentLockFailureAffectsPostOperations()), these commands are only executed once the cache is stopped and at that point the cache is undefined, i.e. {code}2011-12-20 11:04:37,296 1353 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (main:) NodeA-21646 broadcasting call TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<NodeA-21646>:1:local, cacheName=___defaultcache} to recipient list null ... 2011-12-20 11:04:37,329 1386 DEBUG [org.infinispan.CacheImpl] (main:) Stopping cache ___defaultcache on NodeB-21723 ... 2011-12-20 11:04:37,330 1387 DEBUG [org.infinispan.transaction.TransactionTable] (main:) Wait for on-going transactions to finish for 2 seconds. ... 2011-12-20 11:04:37,331 1388 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,Infinispan-Cluster,NodeB-21723:) Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<NodeA-21646>:1:local, cacheName=___defaultcache} [sender=NodeA-21646] 2011-12-20 11:04:37,332 1389 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (Incoming-2,Infinispan-Cluster,NodeB-21723:) Strict peer to peer off, so silently ignoring that ___defaultcache cache is not defined {code} There's a couple of interesting things here: 1. When a cache is stopped, the cache definition is cleared and so no TxCompletionNotificationCommand can execute, so trying to wait for remote transactions to useless. 2. I dunno whether is chance and or there's some other reason behind it, but it appears as if the 'Incoming-' thread takes time to kick off, around 40ms. Might be just timing... I think we need a better solution for 1) was (Author: galder.zamarreno): TxCompletionNotificationCommand is used to remove remote transactions and this is sent asynchronously. However, sometimes when the test is executed (org.infinispan.lock.APITest.testSilentLockFailureAffectsPostOperations()), these commands are only executed once the cache is stopped and at that point the cache is undefined, i.e. {code}2011-12-20 11:04:37,296 1353 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (main:) NodeA-21646 broadcasting call TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<NodeA-21646>:1:local, cacheName=___defaultcache} to recipient list null ... 2011-12-20 11:04:37,329 1386 DEBUG [org.infinispan.CacheImpl] (main:) Stopping cache ___defaultcache on NodeB-21723 ... 2011-12-20 11:04:37,330 1387 DEBUG [org.infinispan.transaction.TransactionTable] (main:) Wait for on-going transactions to finish for 2 ... 2011-12-20 11:04:37,331 1388 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,Infinispan-Cluster,NodeB-21723:) Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<NodeA-21646>:1:local, cacheName=___defaultcache} [sender=NodeA-21646] 2011-12-20 11:04:37,332 1389 TRACE [org.infinispan.remoting.InboundInvocationHandlerImpl] (Incoming-2,Infinispan-Cluster,NodeB-21723:) Strict peer to peer off, so silently ignoring that ___defaultcache cache is not defined seconds. {code} There's a couple of interesting things here: 1. When a cache is stopped, the cache definition is cleared and so no TxCompletionNotificationCommand can execute, so trying to wait for remote transactions to useless. 2. I dunno whether is chance and or there's some other reason behind it, but it appears as if the 'Incoming-' thread takes time to kick off, around 40ms. Might be just timing... I think we need a better solution for 1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira