December 2009 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1561) Issue on view change with single cache store

by Mircea Markus (JIRA)

Issue on view change with single cache store -------------------------------------------- Key: JBCACHE-1561 URL: https://jira.jboss.org/jira/browse/JBCACHE-1561 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mircea Markus Assignee: Manik Surtani -- 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, 11 months

3
4
0 / 0

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

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1563) With READ_COMMITTED, data from invalidated nodes is still visible to txs that read before the invalidation

by Brian Stansberry (JIRA)

With READ_COMMITTED, data from invalidated nodes is still visible to txs that read before the invalidation ---------------------------------------------------------------------------------------------------------- Key: JBCACHE-1563 URL: https://jira.jboss.org/jira/browse/JBCACHE-1563 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.1.GA Reporter: Brian Stansberry Assignee: Manik Surtani With R_C, if a tx reads a node and then another, remote, tx invalidates that node, if the first tx reads the node again it sees the old, stale data. Basically, more of a REPEATABLE_READ behavior. See Dec 23 discussion on the forum thread. This includes a test case. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1562) CacheConfigsXmlParsert can't parse a valid document

by Brian Stansberry (JIRA)

CacheConfigsXmlParsert can't parse a valid document --------------------------------------------------- Key: JBCACHE-1562 URL: https://jira.jboss.org/jira/browse/JBCACHE-1562 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.1.GA Reporter: Brian Stansberry Assignee: Manik Surtani The logic in CacheConfigsXmlParser for distinguishing a legacy config from one using the 3.x schema ends up treating a 3.x config file as legacy. Result is you end up with a default Configuration object! public Map<String, Configuration> parseConfigs(InputStream stream, String fileName) throws CloneNotSupportedException { // loop through all elements in XML. Element root = getDocumentRoot(stream); NodeList list = root.getElementsByTagName(CONFIG_ROOT); if (list == null || list.getLength() == 0) { // try looking for a QUALIFIED_CONFIG_ROOT list = root.getElementsByTagName(QUALIFIED_CONFIG_ROOT); if (list == null || list.getLength() == 0) throw new ConfigurationException("Can't find " + CONFIG_ROOT + " or " + QUALIFIED_CONFIG_ROOT + " tag"); } Map<String, Configuration> result = new HashMap<String, Configuration>(); for (int i = 0; i < list.getLength(); i++) { Node node = list.item(i); if (node.getNodeType() != Node.ELEMENT_NODE) { continue; } Element element = (Element) node; String name = element.getAttribute(CONFIG_NAME); if (name == null || name.trim().length() == 0) throw new ConfigurationException("Element " + element + " has no name attribute"); XmlConfigurationParser parser = new XmlConfigurationParser(); Configuration c; if (parser.isValidElementRoot(element)) { .... parse it } else .... use legacy parser Problem is in XmlConfigurationParsert.isValidElementRoot() public boolean isValidElementRoot(Element element) { // simply test for the "jbosscache" element. NodeList elements = element.getElementsByTagName("jbosscache"); return elements != null && elements.getLength() > 0; } <registry:cache-config/> or <cache-config/> fail that 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

15 years

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1560) Improve documentation on lockParentForChildInsertRemove

by Galder Zamarreno (JIRA)

Improve documentation on lockParentForChildInsertRemove ------------------------------------------------------- Key: JBCACHE-1560 URL: https://jira.jboss.org/jira/browse/JBCACHE-1560 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Locking Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.3.0.GA Take findings in forum post and add them to next user's guide. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1559) 0 ms MVCC timeout for invalidation commands

by Brian Stansberry (JIRA)

0 ms MVCC timeout for invalidation commands ------------------------------------------- Key: JBCACHE-1559 URL: https://jira.jboss.org/jira/browse/JBCACHE-1559 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.1.GA Reporter: Brian Stansberry Assignee: Manik Surtani User reports getting timeout exceptions w/ 0 ms timeouts despite configuring JBC for longer timeouts. See forum thread for specific details. Key bit is here: > The 0 ms is coming from MVCCLockInterceptor: > > Code: > > @Override > public Object handleInvalidateCommand(InvocationContext ctx, InvalidateCommand command) throws Throwable > { > // this should be handled the same as a recursive evict command. > ctx.getOptionOverrides().setLockAcquisitionTimeout(0); > if (!command.getFqn().isRoot()) helper.wrapNodesRecursivelyForRemoval(ctx, command.getFqn()); > return invokeNextInterceptor(ctx, command); > } > > > > I personally don't understand the reasoning behind that; the semantics of an invalidation are not the same as an evict, since an invalidation is concerned with data correctness while an evict is concerned with the > lesser issue of managing memory. > > Perhaps some of the folks who wrote this piece can comment? > > This exception is thrown when a lock is attempted on a remote node. One thing I can think of is that with INVALIDATION_SYNC there is no point waiting more than 0 ms to acquire the lock since whatever is holding > the lock on this node is before releasing it also going to send an invalidation message. Which won't succeed because whatever sent this message will be holding a lock. So might as well fail promptly. > > The above logic doesn't hold true with INVALIDATION_ASYNC though. Galder and I just had a further discussion: Brian: ok, so i think the logical flaw is just that 0 ms isn't correct for ASYNC Galder: hmmm Galder: why? Galder: oh, because they could cross earch other? Brian: well, first off, w/ ASYNC the TimeoutException won't propagate back to the sender, so only issue is what's the best state for the caches to end up in Brian: so, yeah, they'll cross each other and both will invalidate Brian: result is both caches are invalidated Galder: but that's fine Galder: they'll go back to db and get stuff from there Brian: yep Brian: w/ 0 ms timeout, whatever was holding the lock will succeed Brian: because the invalidation msg from the other node will not succeed Brian: so on one node you have potentially inconsistent data left in the cache Galder: oh yeah, the remaining node has stale data Galder: but u have the same problem with sync Brian: w/ sync the TimeoutException propagates, allowing the caller to deal with it Galder: yeah, the failure is at least known Galder: the 2nd node could still succeed but you know the 1st did not Galder: whereas with async, you don't know which one won Brian: right -- 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

1
0
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

15 years

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues December 2009