jbosscache-issues September 2009

jbosscache-issues@lists.jboss.org

1 participants
15 discussions

[JBoss JIRA] Created: (JBCACHE-1541) When modifying evicted node, parent nodes are marked as loaded

by Krzysztof Sobolewski (JIRA)

When modifying evicted node, parent nodes are marked as loaded -------------------------------------------------------------- Key: JBCACHE-1541 URL: https://jira.jboss.org/jira/browse/JBCACHE-1541 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.0.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: ParentDataLoadedTest.java This one's rather simple and it's almost a direct transcription of the test case: 1) Node /a/a/a and all its parents get modified (so that data is non-empty); 2) Node /a is evicted recursively; 3) Node /a/a/a is modified; 4) Parent nodes get created with "dataLoaded" flag set to true and are subsequently not loaded when accessed, appearing empty. I'm also attaching a proposed fix; as usual, I don't know what else might blow up because of it :) -- 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, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1547) 0ms lock acquisition timeout ignored when using putForExternalRead and MVCC.

by Manik Surtani (JIRA)

0ms lock acquisition timeout ignored when using putForExternalRead and MVCC. ---------------------------------------------------------------------------- Key: JBCACHE-1547 URL: https://jira.jboss.org/jira/browse/JBCACHE-1547 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.2.1.CR1, 3.2.1.GA See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160843 -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1543) Remove contention due to PessimisticUnversionedNode.getLock()

by Brian Stansberry (JIRA)

Remove contention due to PessimisticUnversionedNode.getLock() ------------------------------------------------------------- Key: JBCACHE-1543 URL: https://jira.jboss.org/jira/browse/JBCACHE-1543 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Locking Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.2.1.CR1 PessimisticUnversionedNode.getLock() shows up as a middling contention hotspot in profiling tests. The method always calls initLock(), which is a synchronized method. So any lock attempts will first have to briefly get the monitor for the node before they can move on to acquiring the lock. This adds contention in the case of for higher level structural nodes in a tree (e.g. Fqn.ROOT). Solution is to make the PessimisticNodeLock.lock field volatile and then only call initLock() if it is null; aka double-checked locking. Making the field volatile ensures that the IdentityLock object is fully constructed before it is visible to other threads reading PessimisticUnversionedNode.lock, which is the requirement for making double-checked locking correct. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1542) Fix serialVersionUID incompatibility

by Brian Stansberry (JIRA)

Fix serialVersionUID incompatibility ------------------------------------ Key: JBCACHE-1542 URL: https://jira.jboss.org/jira/browse/JBCACHE-1542 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 3.2.1.CR1 Tests of serialVersionUID compatibility fail for 3.2.1.BETA1: FAIL: serialVersionUID error for org.jboss.cache.Fqn, 501 -6901735117605327068, current: -4642221226757627897 FAIL: serialVersionUID error for org.jboss.cache.RegionRegistry, 501 -2480683437308480252, current: 5273358205463079326 For Fqn, the readExternal impl is unchanged; the class just needs a serialVersionUID field. Probably the same for RegionRegistry, which AFAIK really isn't meant to be serialized anyway. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1539) Combination of getChildrenNames() and getData() can lead to overwrite of child's data

by Krzysztof Sobolewski (JIRA)

Combination of getChildrenNames() and getData() can lead to overwrite of child's data ------------------------------------------------------------------------------------- Key: JBCACHE-1539 URL: https://jira.jboss.org/jira/browse/JBCACHE-1539 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Transactions Affects Versions: 3.2.0.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: DataOverwriteTest.java [It is past midnight here and I've just finished tracking this bug...] The attached test illustrates the problem well. The problem is this sequence of events: 1) The node is in the cache store only; 2) A node's key is updated; 3) getChildrenNames() on the node's parent is called; 4) getData() on the node is called; The result of step 4 is the node's data from before modification in step 2. This results in an unpleasant situation where the write seems to get completely lost. It gets lost because it's being overwritten by the cache loader in step 4; it gets overwritten because the node's "data loaded" flag gets set to false in step 3 [1]; the flag gets set to false because the node's "created" flag is true, as returned from wrapNodeForWriting() [2]; the flag is true because the node *is* new, as it's been just loaded from cache loader in step 2. This happens only for getData() because with this command the allKeys flag in mustLoad() is true [3]. [1] CacheLoaderInterceptor:451 [2] CacheLoaderInterceptor:397 - invoked for each child which has "created" flag true [3] CacheLoaderInterceptor:433 The reference [3] provides a workaround: instead of calling getData() you can pick the keys individually. But I'm also pretty sure the bug happens with getKeys() too. -- 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, 3 months

1
1
0 / 0

← Newer
1
2
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues September 2009