November 2008 - jbosscache-issues

[JBoss JIRA] Created: (JBCACHE-1440) Better perfoming cache loader for JDBM

by Elias Ross (JIRA)

Better perfoming cache loader for JDBM -------------------------------------- Key: JBCACHE-1440 URL: https://jira.jboss.org/jira/browse/JBCACHE-1440 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani Patch to add JdbmCacheLoader2 This non-backwards compatible version fixes some performance issues with getChildNames(), stores an entire Map not just a key. The store Map not key structure more naturally matches the granularity of cache loader operations. (For post 3.0 release I think.) -- 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
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1417) Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size

by Manik Surtani (JIRA)

Dynamic resizing of shared lock collection for MVCC write locks based on load/cache size ---------------------------------------------------------------------------------------- Key: JBCACHE-1417 URL: https://jira.jboss.org/jira/browse/JBCACHE-1417 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA A few ideas here: Users could provide a min and max concurrency level, or a factor of number of nodes in the cache. Need to think of an efficient way to resize the lock collection without affecting ongoing operations. Would also need to consider intelligent collection monitoring to make sure hash functions spread nodes across the locks well, otherwise consider altering the hash function. -- 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-1442) Improve performance with "Cache.setData" call

by Elias Ross (JIRA)

Improve performance with "Cache.setData" call --------------------------------------------- Key: JBCACHE-1442 URL: https://jira.jboss.org/jira/browse/JBCACHE-1442 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Elias Ross Assignee: Manik Surtani For a configuration that uses an async cache loader in 3.0, performance of "put(Map m)" may be unexpectedly slow. This is because put(Map) is a merge call and always results in a load. Imagine if put(Map) is being done over the network, e.g. JDBC database. This is not want users would expect. And there's no alternative to this in the current API set. (The work-around is to have cache calls done using a thread pool...) Cache.getNode(X).replaceAll() won't work as it results in a load, and/or a null pointer exception if the node is not found. The old TreeCache from 1.4 had a "put erase" option. I suggest we create a setData() method that does not do a merge. Changes are attached, with some new tests, but I'm not sure the implementation is really complete. The tests set "goals" for the proper behavior of the cache loader. -- 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-1421) Optimize writes on primitives and Strings to short-circuit if there are no changes

by Manik Surtani (JIRA)

Optimize writes on primitives and Strings to short-circuit if there are no changes ---------------------------------------------------------------------------------- Key: JBCACHE-1421 URL: https://jira.jboss.org/jira/browse/JBCACHE-1421 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0 E.g., cache.put(fqn, "key", "Hello"); // tx 1 ... wait ... cache.put(fqn, "key", "Hello"); // tx 2 tx 2 should be able to short-circuit the process if there is no change in the payload. Only makes sense for primitives and Strings though. Even primitive arrays are not worth it since it would involve iterating through the array. -- 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
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1444) ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name.

by Peter Kovgan (JIRA)

ObjectName's validation fails for Jbosscache 3.0 on WAS 6.1 due to ":" char in name. ------------------------------------------------------------------------------------ Key: JBCACHE-1444 URL: https://jira.jboss.org/jira/browse/JBCACHE-1444 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.0.0.CR3 Environment: WAS 6.1, IBM VM Reporter: Peter Kovgan Assignee: Manik Surtani I deploy jboss cache on WAS 6.1(base install), and the problem is: new JmxRegistrationManager uses this function to create unique object name: private void processBaseName(ObjectName baseName) in LOCAL mode, name is objectNameBase = LOCAL_CACHE_PREFIX + Thread.currentThread().getName() + "-" + System.currentTimeMillis(); the problem WAS returns <ContainerName>:<some number> as a Thread.currentThread().getName(). This means you have something like WebContainer : 1 in name, but the ":" char fails during the validation in WAS's proprietary(!!!) javax.management.ObjectName.class. Probably needed some configurable option that excludes ":" Thread.currentThread().getName() - problem part - should be changed for WAS to exclude ":" below is WAS check for invalid characters: while ((in_index < len) && ((c1 = name_chars[in_index++]) != '=')) switch (c1) { // '=' considered to introduce value part case '*' : case '?' : case ',' : case ':' : case '\n' : final String ichar = ((c1=='\n')?"\\n":""+c1); throw new MalformedObjectNameException( "Invalid character '" + ichar + "' in key part of property"); default: ; } -- 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, 11 months

3
13
0 / 0

[JBoss JIRA] Created: (JBCACHE-1406) issue with removing an node in tx

by Mircea Markus (JIRA)

issue with removing an node in tx --------------------------------- Key: JBCACHE-1406 URL: https://jira.jboss.org/jira/browse/JBCACHE-1406 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP9 Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 1.4.X tx.start()' cache.put(/a/b/c); cache.remove(/a/b); cache.put(/a/b/d); tx.commit(); assert "this still exists in the internal structure" : cache.peek(/a/b/c) == null; above assertion fails. The problem is that when tx commits and cache wants to remove /a/b, sees that its not marked for removal (as it was re-added through put(/a/b/d) )and does not look in its children. Method is TreeCache.realRemove, and it;s called from TxInterceptor.commit() UT added to reproduce the issue is: org.jboss.cache.RemoveOnTxTest. -- 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, 12 months

4
13
0 / 0

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

2
7
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

16 years

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1448) Cache loader properties should filter out property-style comments starting with #

by Manik Surtani (JIRA)

Cache loader properties should filter out property-style comments starting with # --------------------------------------------------------------------------------- Key: JBCACHE-1448 URL: https://jira.jboss.org/jira/browse/JBCACHE-1448 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Manik Surtani Assignee: Manik Surtani Priority: Minor Fix For: 3.0.1.CR3, 3.0.1.GA See forum reference -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1446) Optimize activations by minimizing calls to cacheloader.exists()

by Manik Surtani (JIRA)

Optimize activations by minimizing calls to cacheloader.exists() ---------------------------------------------------------------- Key: JBCACHE-1446 URL: https://jira.jboss.org/jira/browse/JBCACHE-1446 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.1.GA See http://lists.jboss.org/pipermail/jbosscache-dev/2008-November/002550.html -- 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

16 years, 1 month

1
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues November 2008