November 2009 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1557) EvictionTimer thread going into endless loop when using LFUAlgorithm

by Guenther Demetz (JIRA)

EvictionTimer thread going into endless loop when using LFUAlgorithm -------------------------------------------------------------------- Key: JBCACHE-1557 URL: https://jira.jboss.org/jira/browse/JBCACHE-1557 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.1.GA Environment: Hibernate3.3.2GA using JBOSSCACHE3.2.1GA as second level cache implementation Database: SQLServer2008 Reporter: Guenther Demetz Assignee: Manik Surtani Background:Im using JBoss-cache 3.2.1 GA as 2L-cache for a Hibernate application. As Hibernate documentation does not suggest LRU as algorithm for 2L-cache, I use the LFU algorithm. At a certain point BaseEvictionAlgorithm#prune method never exits his loop anymore because of evictionQueue.getFirstNodeEntry() always returning the same value. Debugging the code we saw that the actual bug stays in method LFUQueue#removeNodeEntry (see code below) : This method don't handles correctly the case of non-existance of the node in the nodeMap: if ne == null, then neither removalQueue nor the evictionList is touched. This causes evictionQueue.getFirstNodeEntry() returning always the same result. Code: BaseEvictionAlgorithm.java ... protected void prune() throws EvictionException { NodeEntry entry; while ((entry = evictionQueue.getFirstNodeEntry()) != null) --> ENDLESS-LOOP because evict doesn't alter the evictionQueye { if (this.shouldEvictNode(entry)) { this.evict(entry); } else { break; } } } Code: LFUQueue.java: public void removeNodeEntry(NodeEntry entry) { NodeEntry ne = nodeMap.remove(entry.getFqn()); if (ne != null) { // don't remove directly from the LinkedList otherwise we will incur a O(n) = n // performance penalty for every removal! In the prune method for LFU, we will iterate the LinkedList through ONCE // doing a single O(n) = n operation and removal. This is much preferred over running O(n) = n every single time // remove is called. There is also special logic in the getFirstNodeEntry that will know to check // the removalQueue before returning. this.removalQueue.add(ne); /* if(!evictionList.remove(ne)) { throw new RuntimeException(""); } */ this.numElements -= ne.getNumberOfElements(); } } Solution: following Else-block added in method LFUQueue#removeNodeEntry resolves the problem. Code: else { // ELSE BLOCK: bugfix: this prevents endless loop in BaseEvictionAlgorithm#prune method if(!evictionList.remove(entry)) throw new RuntimeException(""); this.removalQueue.add(entry); this.numElements -= entry.getNumberOfElements(); } N.B.: In other parts of the code, i.e BaseEvictionAlgorithm: line 406 the non-existance of the node is properly handled, see following logging outputs: 13:55:11,712 DEBUG BaseEvictionAlgorithm:384 - Removing node /com/wuerth/phoenix/Cis/bc/persistent/jpa/ConcreteAccountPeer/assAccount/COLL/com.wuerth.phoenix.Cis.bc.persistent.jpa.ConcreteAccountPeer.assAccount#32770 from eviction queue and attempting eviction 13:55:11,712 DEBUG BaseEvictionAlgorithm:406 - processRemoveNodes(): Can't find node associated with fqn: /com/wuerth/phoenix/Cis/bc/persistent/jpa/ConcreteAccountPeer/assAccount/COLL/com.wuerth.phoenix.Cis.bc.persistent.jpa.ConcreteAccountPeer.assAccount#32770Could have been evicted earlier. Will just continue. regards G.D. -- 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

14 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1551) Locking parent node

by Nikolay Shestakov (JIRA)

Locking parent node ------------------- Key: JBCACHE-1551 URL: https://jira.jboss.org/jira/browse/JBCACHE-1551 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.1.GA, 3.2.0.GA Reporter: Nikolay Shestakov Assignee: Manik Surtani I have next test: @Test public void nodes() { // setup Fqn<String> fqn1 = Fqn.fromElements(UUID.randomUUID().toString().replace("-", "")); String attribute1 = UUID.randomUUID().toString().replace("-", ""); String value1 = UUID.randomUUID().toString().replace("-", ""); Fqn<String> fqn2 = Fqn.fromElements(UUID.randomUUID().toString().replace("-", "")); String attribute2 = UUID.randomUUID().toString().replace("-", ""); String value2 = UUID.randomUUID().toString().replace("-", ""); Assert.assertFalse(fqn1.equals(fqn2)); // call TransactionHelper.begin(); _cache.put(fqn1, attribute1, value1); TransactionHelper.begin(); // suspend and begin new _cache.put(fqn2, attribute2, value2); TransactionHelper.commit(); TransactionHelper.commit(); // assertions Assert.assertEquals(value1, _cache.get(fqn1, attribute1)); Assert.assertEquals(value2, _cache.get(fqn2, attribute2)); // clear } sometimes this test is fail (~ one time from 1000 executions): Unable to acquire lock on Fqn [/test19cb7eae7cc546b1909261c289] after [10000] milliseconds for requestor [GlobalTransaction:<null>:3]! Lock held by [GlobalTransaction:<null>:2] at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159) at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:236) at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186) at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101) at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) config file is: <?xml version="1.0" encoding="UTF-8"?> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.2"> <transaction transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup" /> <locking isolationLevel="REPEATABLE_READ" lockParentForChildInsertRemove="false" nodeLockingScheme="mvcc" /> <jmxStatistics enabled="true" /> </jbosscache> -- 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

14 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1558) Deadlock in POJO cache

by Roman Mandeleil (JIRA)

Deadlock in POJO cache ---------------------- Key: JBCACHE-1558 URL: https://jira.jboss.org/jira/browse/JBCACHE-1558 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.1.GA Reporter: Roman Mandeleil Assignee: Manik Surtani Priority: Critical I got a deadlock in a very simple test of POJO cache: ArrayList aspectized and placed in the cache. Two different Threads trying to insert elements into ArrayList and bumped into a deadlock. -- 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

14 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1556) A race to "children loaded" flag in CacheLoadedInterceptor.loadChildren()

by Krzysztof Sobolewski (JIRA)

A race to "children loaded" flag in CacheLoadedInterceptor.loadChildren() ------------------------------------------------------------------------- Key: JBCACHE-1556 URL: https://jira.jboss.org/jira/browse/JBCACHE-1556 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Transactions Affects Versions: 3.2.1.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: ChildrenLoadingRaceTest-fix.diff, ChildrenLoadingRaceTest.java We found a race in CacheLoaderInterceptor.loadChildren() that goes like this: 1) There is a node /a with evicted children /a/a and /a/b; the node itself is *not* evicted 2) Transaction T1 wants to get the children list of /a 3) Transaction T2 wants to get the children list of /a 4) T1 gets to loadChildren() for /a, notices that the children are not loaded and proceeds to load them 4a) T1 loads the children and sets "children loaded" flag to true, but holds the names themselves in its context [this depends on isolation level, I guess] 5) T2 gets to the same point and sees that "children loaded" flag is set, so it skips loading 6a) T1 correctly returns "a" and "b" 6b) T2 returns whatever was in memory at that point [in the attached test it's "a", but I would expect empty set] I fixed it by acquiring a lock on the parent node, forcing both transactions to serialize the access (but not preventing from loading the children twice). The patch depends on the one proposed for JBCACHE-1553 (it's in the same place and they interact in non-trivial way) Also note that the "lock parent for child insert remove" config option does not affect the result of the test. -- 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

14 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1553) Potential possibility to avoid some (most?) locking in CacheLoaderInterceptor.loadChildren()

by Krzysztof Sobolewski (JIRA)

Potential possibility to avoid some (most?) locking in CacheLoaderInterceptor.loadChildren() -------------------------------------------------------------------------------------------- Key: JBCACHE-1553 URL: https://jira.jboss.org/jira/browse/JBCACHE-1553 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.1.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: LoadChildrenChildLockingTest.java We create new nodes in memory with "children loaded" flag always set to false, because we cannot efficiently check whether this is a purely new node or it exists in evicted state. This flag can be happily set to false for a very long time, until someone calls getChildrenNames() (or similar); at this moment CacheLoaderInterceptor decides it must load the node's children from the cache loader, in case there are some that weren't accessed recently enough for them to be activated. In the process, it locks the node *and* all the children nodes. I think the locking of children can be avoided if the child was already in memory. I filed this as a bug because it caused real problems in our application (with locking in unexpected moments and places). I'm attaching a test case and a patch that worked for me, but, as usual, causes unknown collateral damage :) -- 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

14 years, 6 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1554) JBoss Cache 3.0.0 Pojo userguide punctuation error

by Brett Cave (JIRA)

JBoss Cache 3.0.0 Pojo userguide punctuation error -------------------------------------------------- Key: JBCACHE-1554 URL: https://jira.jboss.org/jira/browse/JBCACHE-1554 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Training Affects Versions: 3.0.0.GA Environment: JBoss Cache Pojo Userguide 3.0.0, PDF version (unverified in src xml or HTML version) Reporter: Brett Cave Assignee: Bela Ban Priority: Minor On pg 47 of PDF version - Chapter 8. Appendix, Section 2 - Sample Cache configuration: 4800 added as extra timeout param for unicast from previous version, but was added outside of inverted comma's: <UNICAST timeout="600,1200,2400",4800/> should be <UNICAST timeout="600,1200,2400,4800" /> -- 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

14 years, 6 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 November 2009