[JBoss JIRA] (ISPN-1545) Enhance logging during cache shutdown
by Mircea Markus (Created) (JIRA)
Enhance logging during cache shutdown
-------------------------------------
Key: ISPN-1545
URL: https://issues.jboss.org/browse/ISPN-1545
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA5
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.1.0.CR1
When cache shuts down the transaction table recalculates its minViewId value based on the new topology. When the whole cluster shuts down though, the thread that recalculates might throw an exception (expected) because it's internal components (RPC in this example) are not responding anymore. This causes a lot of log noise in the logs, which should be removed:
2011-11-16 17:08:29,045 WARN [jta] (Transaction Reaper Worker 0) ARJUNA16045: attempted rollback of < formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffac11fa3e:c0a2:4ec3df75:a055, node_name=1, branch_uid=0:ffffac11fa3e:c0a2:4ec3df75:a056, eis_name=unknown eis name > (TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=< formatId=131076, gtrid_length=29, bqual_length=28, tx_uid=0:ffffac11fa3e:c0a2:4ec3df75:a055, node_name=1, branch_uid=0:ffffac11fa3e:c0a2:4ec3df75:a056, eis_name=unknown eis name >} LocalTransaction{remoteLockedNodes=[9124b480-6ae0-5267-d9f8-3d66ea7ec581, 86c0fc2d-a0da-adb4-5343-940d6bdb1aa0], isMarkedForRollback=true, transaction=TransactionImple < ac, BasicAction: 0:ffffac11fa3e:c0a2:4ec3df75:a055 status: ActionStatus.ABORTING >, lockedKeys=null, backupKeyLocks=null, viewId=1} org.infinispan.transaction.xa.LocalXaTransaction@2947}) failed with exception code -
org.infinispan.CacheException: The cache has been stopped and invocations are not allowed!
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getViewId(JGroupsTransport.java:197)
at org.infinispan.transaction.TransactionTable.getCurrentViewId(TransactionTable.java:372)
at org.infinispan.transaction.TransactionTable.recalculateMinViewIdIfNeeded(TransactionTable.java:387)
at org.infinispan.transaction.TransactionTable.removeLocalTransactionInternal(TransactionTable.java:318)
at org.infinispan.transaction.TransactionTable.removeLocalTransaction(TransactionTable.java:306)
at org.infinispan.transaction.xa.XaTransactionTable.removeLocalTransaction(XaTransactionTable.java:61)
at org.infinispan.transaction.TransactionTable.failureCompletingTransaction(TransactionTable.java:188)
at org.infinispan.transaction.TransactionCoordinator.rollback(TransactionCoordinator.java:145)
at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:136)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:337)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2869)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2848)
at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1613)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:119)
at com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:212)
at com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:367)
at com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:79)
--
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
12 years, 11 months
[JBoss JIRA] (ISPN-1546) FineGrainedAtomicMap key and value iterators are not threadsafe
by Sanne Grinovero (Created) (JIRA)
FineGrainedAtomicMap key and value iterators are not threadsafe
---------------------------------------------------------------
Key: ISPN-1546
URL: https://issues.jboss.org/browse/ISPN-1546
Project: Infinispan
Issue Type: Bug
Components: Core API, Locking and Concurrency
Reporter: Sanne Grinovero
Assignee: Manik Surtani
Invoking #keySet() or #values() might fail, even when using a transaction to isolate threads:
{code}
java.util.ConcurrentModificationException
at org.infinispan.util.FastCopyHashMap$FasyCopyHashMapIterator.nextEntry(FastCopyHashMap.java:484)
at org.infinispan.util.FastCopyHashMap$KeyIterator.next(FastCopyHashMap.java:560)
at java.util.AbstractCollection.addAll(AbstractCollection.java:305)
at org.infinispan.atomic.FineGrainedAtomicHashMapProxy.keySet(FineGrainedAtomicHashMapProxy.java:104)
at org.hibernate.ogm.dialect.infinispan.InfinispanAssociationSnapshot.getRowKeys(InfinispanAssociationSnapshot.java:59)
at org.hibernate.ogm.datastore.spi.Association.getKeys(Association.java:132)
at org.hibernate.ogm.loader.OgmLoader.getResultSet(OgmLoader.java:420)
at org.hibernate.ogm.loader.OgmLoader.doQuery(OgmLoader.java:248)
at org.hibernate.ogm.loader.OgmLoader.doQueryAndInitializeNonLazyCollections(OgmLoader.java:215)
at org.hibernate.ogm.loader.OgmLoader.loadCollection(OgmLoader.java:185)
at org.hibernate.ogm.loader.OgmBasicCollectionLoader.initialize(OgmBasicCollectionLoader.java:42)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:622)
at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:82)
at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1607)
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:379)
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:112)
at org.hibernate.collection.internal.PersistentSet.iterator(PersistentSet.java:180)
{code}
--
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
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1429) remove lock guards(if trace.enabled() .. ) where possible
by Mircea Markus (JIRA)
remove lock guards(if trace.enabled() .. ) where possible
---------------------------------------------------------
Key: ISPN-1429
URL: https://issues.jboss.org/browse/ISPN-1429
Project: Infinispan
Issue Type: Enhancement
Reporter: Mircea Markus
Assignee: Manik Surtani
Citing from David Lloyd's email:
<snip>
If you're using the jboss-logging API, and your log statement does not
do any interpolation, then it is just as fast to do any of the following
(with no if):
log.trace("blah");
log.tracef("the %s happened to %s", foo, bar);
log.tracev("the {0} happened to {1}", foo, bar);
In the case where trace logging is disabled, these are exactly as
efficient as the if (log.isTraceEnabled()) variants. In the case where
it is enabled, it is marginally more efficient (though the trace log
itself is substantially more expensive of course).
Overall I'd avoid the "if" forms unless you're doing complex interpolation:
log.trace("Foo " + bar + " baz " + zap);
log.tracef("the %s happened to %s", fooMethod().barMethod(), bar);
...both of which incur the expense of the expression resolution even if
the log message is ultimately discarded.
</snip>
This JIRA is about:
1. removing all the "if (trace)" statements from the code (where possible, see below)
2. making sure that this is a documented policy and people are aware of it
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] (ISPN-1542) InvocationContext should not keep entries in an BidirectionalLinkedHashMap
by Mircea Markus (Created) (JIRA)
InvocationContext should not keep entries in an BidirectionalLinkedHashMap
--------------------------------------------------------------------------
Key: ISPN-1542
URL: https://issues.jboss.org/browse/ISPN-1542
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
ATM the InvocationContext keeps the looked up entries in an BidirectionalLinkedHashMap. It uses the BidirectionalLinkedHashMap in order to commit the entries in the reversed order in which they were added to the context. This is an inherited feature from JBossCache, where it made sense due to cache's tree structure. It doesn't make sense in Infinispan though, and it adds an unnecessary burden to the InvocationContext.
The problem is particularly performance costly in the case of non-tx caches, where most of the operations only need a single entry lookup to be held in the invocation context.
--
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
12 years, 11 months
[JBoss JIRA] Created: (ISPN-1309) Provide a way to use Flags without resorting to a ThreadLocal
by Sanne Grinovero (JIRA)
Provide a way to use Flags without resorting to a ThreadLocal
-------------------------------------------------------------
Key: ISPN-1309
URL: https://issues.jboss.org/browse/ISPN-1309
Project: Infinispan
Issue Type: Feature Request
Reporter: Sanne Grinovero
Assignee: Manik Surtani
Fix For: 6.0.0.FINAL
A brief performance analysis highlighted a significant impact on performance because of the use of ThreadLocals to hold the enabled flags in the current context.
We should check these findings with a proper test and provide an alternative way, ideally one which doesn't need to lookup in the flagHolder either (avoid both the put and the get in the threadlocal).
We'll need a method which returns a new Cache instance having the mentioned Flags always implicitly added to the invocation context. I think it would be fine in such an alternative implementation to not support dynamic flags.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months