[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
13 years
[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
13 years
[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
13 years
[JBoss JIRA] (ISPN-1640) Installing a merged cache view takes too long
by Dan Berindei (Created) (JIRA)
Installing a merged cache view takes too long
---------------------------------------------
Key: ISPN-1640
URL: https://issues.jboss.org/browse/ISPN-1640
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.1.0.CR1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.1.0.FINAL
When the CacheViewsManager running on the merge coordinator receives the merged view, it immediately sends a StateTransferControlCommand{type=RECOVER_VIEW} to all the other members of the cluster do discover their installed views.
Sometimes the RECOVER_VIEW command reaches a node from the other partition before the merged view is installed on that node, and the message is dropped. The coordinator will eventually retry sending the message and succeed the second time, but the retry time can be up to 50 seconds with the default JGroups configuration.
I've discussed with Bela several possible workarounds:
1. Wait a short amount of time before sending the RECOVER_VIEW command.
2. Send the RECOVER_VIEW command as unicasts.
3. Use the RSVP flag for the RECOVER_VIEW command (once we upgrade to JGroups 3.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
13 years