January 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1604) use1PCForAutoCommitTransactions not completely added to new configuration

by Pete Muir (Created) (JIRA)

use1PCForAutoCommitTransactions not completely added to new configuration ------------------------------------------------------------------------- Key: ISPN-1604 URL: https://issues.jboss.org/browse/ISPN-1604 Project: Infinispan Issue Type: Bug Components: Configuration, Transactions Affects Versions: 5.1.0.CR1 Reporter: Pete Muir Assignee: Mircea Markus Fix For: 5.1.0.CR2 It's been added to the builder, but not the configuration class it builds, nor to the legacy adaptor or read methods. -- 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, 8 months

5
4
0 / 0

[JBoss JIRA] (ISPN-1637) AsyncStore.enqueue() throws 'CacheException: Unable to enqueue asynchronous task' Instead of blocking when the queue is full

by Andrew Pushkin (Created) (JIRA)

AsyncStore.enqueue() throws 'CacheException: Unable to enqueue asynchronous task' Instead of blocking when the queue is full ---------------------------------------------------------------------------------------------------------------------------- Key: ISPN-1637 URL: https://issues.jboss.org/browse/ISPN-1637 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.CR1 Reporter: Andrew Pushkin Assignee: Manik Surtani Documentation http://docs.jboss.org/infinispan/5.1/apidocs/config.html#ce_loader_async : "modificationQueueSize int 1024 Sets the size of the modification queue for the async store. If updates are made at a rate that is faster than the underlying cache store can process this queue, then the async store behaves like a synchronous store for that period, blocking until the queue can accept more elements. (Javadoc)" However the async store doesn't "behaves like synchronous [...] blocking until the queue can accept more elements" because AsyncStore.enqueue() calls changesDeque.add(mod); But I guess it should call put() to wait queue to accept more elements. -- 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, 8 months

4
4
0 / 0

[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, 8 months

5
6
0 / 0

[JBoss JIRA] (ISPN-1647) ValueWrapperImpl Class Not Found error after upgrading Spring3.1RC to Spring 3.1 Release

by YILDIRIM ADIGUZEL (Created) (JIRA)

ValueWrapperImpl Class Not Found error after upgrading Spring3.1RC to Spring 3.1 Release ---------------------------------------------------------------------------------------- Key: ISPN-1647 URL: https://issues.jboss.org/browse/ISPN-1647 Project: Infinispan Issue Type: Bug Components: Spring integration Affects Versions: 5.1.0.CR2 Reporter: YILDIRIM ADIGUZEL Assignee: Manik Surtani Priority: Minor Fix For: 5.1.0.CR3 ValueWrapperImpl removed from spring-context in version spring-context-3.1.0.RELEASE.jar. The infinispan-spring.jar compiled with the spring-context-3.1.0.RC1.jar. Infinispan-spring project Spring references should be upgraded to the 3.1.0.RELEASE. -- 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, 8 months

10
9
0 / 0

[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, 8 months

5
7
0 / 0

[JBoss JIRA] (ISPN-1686) LegacyConfigurationAdaptor loses transactionSynchronizationRegistryLookup

by Paul Ferraro (Created) (JIRA)

LegacyConfigurationAdaptor loses transactionSynchronizationRegistryLookup ------------------------------------------------------------------------- Key: ISPN-1686 URL: https://issues.jboss.org/browse/ISPN-1686 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.1.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Blocker Fix For: 5.1.0.CR3 -- 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, 8 months

4
3
0 / 0

[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, 8 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1681) Lucene Directory should use SKIP_CACHE_LOAD as well

by Sanne Grinovero (Created) (JIRA)

Lucene Directory should use SKIP_CACHE_LOAD as well --------------------------------------------------- Key: ISPN-1681 URL: https://issues.jboss.org/browse/ISPN-1681 Project: Infinispan Issue Type: Enhancement Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.0.CR3 -- 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, 8 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1676) Remove deprecated code from Lucene Directory

by Sanne Grinovero (Created) (JIRA)

Remove deprecated code from Lucene Directory -------------------------------------------- Key: ISPN-1676 URL: https://issues.jboss.org/browse/ISPN-1676 Project: Infinispan Issue Type: Task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 5.1.0.CR3 -- 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, 8 months

3
2
0 / 0

[JBoss JIRA] (ISPN-1677) Reuse decorated caches in Lucene

by Sanne Grinovero (Created) (JIRA)

Reuse decorated caches in Lucene -------------------------------- Key: ISPN-1677 URL: https://issues.jboss.org/browse/ISPN-1677 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 5.1.0.CR3 -- 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, 8 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2012