February 2009 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1469) DummyBaseTransactionManager behaves incorrectly with Status.STATUS_MARKED_ROLLBACK

by Manik Surtani (JIRA)

DummyBaseTransactionManager behaves incorrectly with Status.STATUS_MARKED_ROLLBACK ---------------------------------------------------------------------------------- Key: JBCACHE-1469 URL: https://jira.jboss.org/jira/browse/JBCACHE-1469 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.3.GA When an ongoing transaction has been marked as STATUS_MARKED_ROLLBACK, calling commit() simply throws a RollbackException() and does not actually attempt a rollback (which would involve notifying Synchronizations, etc). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1473) Cache Regions lose capacity - EvictCommand.perform() causes dead entries in EvictionQueue

by Roberto Tyley (JIRA)

Cache Regions lose capacity - EvictCommand.perform() causes dead entries in EvictionQueue ----------------------------------------------------------------------------------------- Key: JBCACHE-1473 URL: https://jira.jboss.org/jira/browse/JBCACHE-1473 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.0.2.GA Reporter: Roberto Tyley Assignee: Manik Surtani There is a serious bug in EvictCommand.perform() which leads to cache regions declining in effective capacity over time. The syndrome is: * Cache fails to fill - node count initially reaches around 90% of configured maxNodes capacity * Cache capacity declines over time - in our case down to 70% of capacity after 36 hours. In order to manifest this issue, you need to be removing as well as adding nodes to the cache. The bug is exposed by a race condition between the Client Code thread removing a node and the Eviction Thread processing the EvictionEventQueue, but the race condition is not the problem (the race condition just explains why you don't see this issue all the time), the problem is with the semantics of the boolean return value of EvictCommand.perform(). Failure Case: EvictCommand.perform() tries to evict a node X from the cache, when X is no longer in the cache: * the EvictCommand.perform() method returns the boolean 'false', attempting to indicate: "the EvictCommand has done no work" * the EvictionInterceptor interprets the return value of 'false' to mean: "only data has been removed from the node X, and the node still exists in the cache". As a consequence the EvictionInterceptor creates a new ADD_NODE_EVENT for X, to ensure that X will be revisited by the eviction thread in future, and adds the event to theEvictionQueue. The EvictionQueue now contains a NodeEntry for a Node which is not in the cache. The EvictionAlgorithm will evict nodes based on how many nodes it *thinks* are in the cache (the length of its EvictionQueue), rather than how many nodes are /actually/ in the cache, so the cache can not grow to it's full capacity. These dead NodeEntries build up over time and can take up a substantial portion of your cache if you're frequently performing node removals. The fix for this issue is thankfully simple: As only EvictionInterceptor reads the boolean value returned by EvictCommand.perform(), the semantics of the return value should be aligned with those of the EvictionInterceptor, and should simply return whether the node STILL exists in the cache after the evict has been performed, as that is what the EvictionInterceptor is really interested in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
11
0 / 0

[JBoss JIRA] Created: (JBCACHE-1477) Possible bug in JDBC cache loader SQL on Informix

by Manik Surtani (JIRA)

Possible bug in JDBC cache loader SQL on Informix ------------------------------------------------- Key: JBCACHE-1477 URL: https://jira.jboss.org/jira/browse/JBCACHE-1477 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.2.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0.GA Needs investigation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1471) Slow cache.get for fqn with a large number of key/value entries.

by Alex Kluge (JIRA)

Slow cache.get for fqn with a large number of key/value entries. ---------------------------------------------------------------- Key: JBCACHE-1471 URL: https://jira.jboss.org/jira/browse/JBCACHE-1471 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 3.0.2.GA Environment: Encountered when using a TcpDelegatingCacheLoader Reporter: Alex Kluge Assignee: Manik Surtani Priority: Minor Stress tests of JBoss Cache with a far cache, and a large number (10K+) of key/value pairs in a node did not perform as well as I would expect. On a read of the cache, cache.get(fqn, key), a large amount of time was spent determining whether the data needed to be loaded from the far cache. The big time sink is the n. getKeysDirect() call in org.jboss.cache.interceptors.CacheLoaderInterceptor, which copies the keyset. As expected, introducing a containsKeyDirect(K key) method to NodeSPI, and implementation classes where needed, allowed for a significant speedup when the new method is used in place of n.getKeysDirect().contains(key). If this is a reasonable path, I have attached the patch file to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1475) Rolled back transactions sometimes failing to release locks

by Nathan Messer (JIRA)

Rolled back transactions sometimes failing to release locks ----------------------------------------------------------- Key: JBCACHE-1475 URL: https://jira.jboss.org/jira/browse/JBCACHE-1475 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA, 3.0.0.GA Environment: Windows XP, Weblogic 10.3, Single instance, JBoss Cache in Local Mode, using MVCC locking scheme Reporter: Nathan Messer Assignee: Manik Surtani Rolled back transactions sometimes failing to release locks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBCACHE-1366) state transfer optimisation (with preload, and in memory state transfer)

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1366?page=com.atlassian.jira.p... ] Manik Surtani commented on JBCACHE-1366: ---------------------------------------- will be obsolete with JBCACHE-1236 > state transfer optimisation (with preload, and in memory state transfer) > ------------------------------------------------------------------------ > > Key: JBCACHE-1366 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1366 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > > Optimization can be done in in a configuration where the following are true: > - prelaod > - in-memory state transfer is enabled > - no passivation > - a) shared cache loader OR b)fetch persistent state > Optimization:during in-memory state transfer frome cache ONE to cache TWO, do not transfer the regions which in cache TWO were set for preloading. > a) is shared cache loader is on that these regions will be loaded from the store anyhow, so transfer of these regions is redundant > b) the content of these regions will be transfered at persistent state transfer anyway, so again redundancy during in-memory state transfer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1366) state transfer optimisation (with preload, and in memory state transfer)

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1366?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1366. ------------------------------------ Fix Version/s: (was: 3.1.0.GA) Resolution: Won't Fix > state transfer optimisation (with preload, and in memory state transfer) > ------------------------------------------------------------------------ > > Key: JBCACHE-1366 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1366 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Minor > > Optimization can be done in in a configuration where the following are true: > - prelaod > - in-memory state transfer is enabled > - no passivation > - a) shared cache loader OR b)fetch persistent state > Optimization:during in-memory state transfer frome cache ONE to cache TWO, do not transfer the regions which in cache TWO were set for preloading. > a) is shared cache loader is on that these regions will be loaded from the store anyhow, so transfer of these regions is redundant > b) the content of these regions will be transfered at persistent state transfer anyway, so again redundancy during in-memory state transfer -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-971) Eviction policy based on adaptive replacement

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-971?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-971: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Eviction policy based on adaptive replacement > --------------------------------------------- > > Key: JBCACHE-971 > URL: https://jira.jboss.org/jira/browse/JBCACHE-971 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 3.2.0.GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Quote from Mircea Markus: > There is an eviction policy algorithm more efficient than LRU (which I found quite popular) - Adaptive Replacement Policy. The basic idea is to not rely only on the time of last access to the node, but also on the number of time(frequency) a given node was accessed. Here it is a nice description of how it works: http://en.wikipedia.org/wiki/Adaptive_Replacement_Cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-1009) Support preload functionality as part of region activation

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1009?page=com.atlassian.jira.p... ] Manik Surtani updated JBCACHE-1009: ----------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Support preload functionality as part of region activation > ---------------------------------------------------------- > > Key: JBCACHE-1009 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1009 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Cache loaders > Reporter: Brian Stansberry > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > Currently a cache loader preload only happens as part of cache start. It could be supported as part of the activateRegion process; i.e. if one of the defined preload regions in the cache loader config encapsulates the region being activated, preload the region. If one of the defined preload regions names a subregion of the region being activated, preload the subregion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-759) Create a set of deadlock-detecting unit tests

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-759?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-759: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > Create a set of deadlock-detecting unit tests > --------------------------------------------- > > Key: JBCACHE-759 > URL: https://jira.jboss.org/jira/browse/JBCACHE-759 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Scripts and processes > Affects Versions: 1.4.0.GA > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Priority: Minor > Fix For: 3.2.0.GA > > > From email thread: > "Okay, found out that jconsole also supports it: > MBeans --> java.lang --> Threading --> Operations --> findMonitorDeadlockedThreads(). > Of course, if we could integrate this into our test suites to regularly check for deadlocks..." > Article from JavaSpecialists: > http://www.javaspecialists.co.za/archive/newsletter.do?issue=130&locale=e... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues February 2009