jbosscache-issues December 2008

jbosscache-issues@lists.jboss.org

1 participants
24 discussions

[JBoss JIRA] Created: (JBCACHE-1412) TreeCacheMarshaller140 marshalling replaces distinct but equal() objects

by Brian Stansberry (JIRA)

TreeCacheMarshaller140 marshalling replaces distinct but equal() objects ------------------------------------------------------------------------ Key: JBCACHE-1412 URL: https://jira.jboss.org/jira/browse/JBCACHE-1412 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.1.SP9 Reporter: Brian Stansberry Assignee: Manik Surtani Priority: Critical The marshalling logic in TreeCacheMarshaller140 uses a HashMap as store of objects already written so it can replace subsequent writes of the same object with a magic number. Use of a HashMap is incorrect, as magic number replacement should only occur if an object with the same identity is detected, not one that just satisfies equals() but not ==. Either a custom map that uses System.identityHashCode() for hashing and == instead of equals() for equality is needed, or the map key should be System.identityHashCode(). Note the Object.hashCode() javadocs do not absolutely guarantee uniqueness in System.identityHashCode(), so a custom map is probably better: "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)" Non-uniquenesss in System.identityHashCode() might be more of an issue in systems with large heaps that can't be addressed with 32 bits. -- 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, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1454) Memory leak in CacheStoreInterceptor

by Krzysztof Sobolewski (JIRA)

Memory leak in CacheStoreInterceptor ------------------------------------ Key: JBCACHE-1454 URL: https://jira.jboss.org/jira/browse/JBCACHE-1454 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.1.GA, 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani The CacheStoreInterceptor leaks Fqns with asynchronous replication (and in local mode, I guess). CacheStoreInterceptor remembers modifications in handlePrepareCommand() and later is supposed to clear it on commit/rollback. The failure is that async turns on one phase commit, in which transaction commit sends PrepareCommand only (instead of Prepare + Commit/Rollback). This way the interceptor accumulates modifications for transactions long gone (in preparingTxs and txStores Maps) I *think* the patch below should fix it, at least for 2.2. It looks like in 3.0 it is even more leaky: onePhase is always(?) false (so the patch won't help) and the preparingTxs are removed from only with optimistic locking (or after exception; or rollback). The patch: Index: src/main/java/org/jboss/cache/interceptors/CacheStoreInterceptor.java =================================================================== --- src/main/java/org/jboss/cache/interceptors/CacheStoreInterceptor.java (revision 6986) +++ src/main/java/org/jboss/cache/interceptors/CacheStoreInterceptor.java (working copy) @@ -371,10 +371,13 @@ { loader.prepare(gtx, modsBuilder.modifications, onePhase); - preparingTxs.put(gtx, modsBuilder.affectedFqns); - if (getStatisticsEnabled() && modsBuilder.putCount > 0) + if (!onePhase) { - txStores.put(gtx, modsBuilder.putCount); + preparingTxs.put(gtx, modsBuilder.affectedFqns); + if (getStatisticsEnabled() && modsBuilder.putCount > 0) + { + txStores.put(gtx, modsBuilder.putCount); + } } } } -- 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, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1447) JDBM cache loader remove of the root childeren doesn't clear the data

by Elias Ross (JIRA)

JDBM cache loader remove of the root childeren doesn't clear the data --------------------------------------------------------------------- Key: JBCACHE-1447 URL: https://jira.jboss.org/jira/browse/JBCACHE-1447 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani " I get another abnormality... removing all children nodes from root using the cahe instance result in a non-empty tree in JDBM (dump() shows nodes but the cache instance, no). Even using CacheLoader directly doesn't remove everything at first." -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1450) putForExternalRead() doesn't use a 0 lock acquisition timeout with MVCC

by Manik Surtani (JIRA)

putForExternalRead() doesn't use a 0 lock acquisition timeout with MVCC ----------------------------------------------------------------------- Key: JBCACHE-1450 URL: https://jira.jboss.org/jira/browse/JBCACHE-1450 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.1.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0 lock acquisition timeout not zeroed for pfer() calls when used with MVCC -- 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, 4 months

1
3
0 / 0

← Newer
1
2
3
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues December 2008