April 2010 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1545) remove does not remove node when using optimistic locking and called on an instance which does not contain the node.

by Dennis Reed (JIRA)

remove does not remove node when using optimistic locking and called on an instance which does not contain the node. -------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1545 URL: https://jira.jboss.org/jira/browse/JBCACHE-1545 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani With optimistic locking, remove ( String fqn ), and remove ( String fgn, Object key ) do not remove from other cluster members if the node does not exist in the local cache. This can happen when using invalidation, or when the node has been evicted. -- 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, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1577) Cannot clear a distributed cache locally

by Nicolas Filotto (JIRA)

Cannot clear a distributed cache locally ---------------------------------------- Key: JBCACHE-1577 URL: https://jira.jboss.org/jira/browse/JBCACHE-1577 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.3.CR1 Reporter: Nicolas Filotto Assignee: Manik Surtani Attachments: removeNodeFix.diff I have a distributed cache and I would like to be able to clear it locally so I used the following code: {code} cache.getInvocationContext().getOptionOverrides().setCacheModeLocal(true); cache.removeNode(Fqn.ROOT); {code} Unfortunatelly, all the nodes are removed in all the cache instances in my cluster. After a deeper investigation, it seems to be a bug in CacheInvocationDelegate.removeNode that doesn't properly set the option overrides since it reuse the same option object that is reset after each call. I attached a unit test and a patch for this bug. -- 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, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBCACHE-1565) Locking doesn't work when replication is used

by tbech (JIRA)

Locking doesn't work when replication is used --------------------------------------------- Key: JBCACHE-1565 URL: https://jira.jboss.org/jira/browse/JBCACHE-1565 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.1.GA Environment: Linux, Sun Java 5.0 Reporter: tbech Assignee: Manik Surtani Priority: Critical Attachments: exc.txt During performance tests of JBossCache, I've tried to test transactions with cache.getInvocationContext().getOptionOverrides().setForceWriteLock operation ('select-for-update'). I've used standard jbosscache benchmark from svn. I've created new product jbosscache3.2.1 based on 3.1.0 and new test. Basicaly it did: try { long startTime = System.nanoTime(); if (concurrentWrites) { cacheWrapper.startTransaction(); cacheWrapper.setForceWriteLock(true); } ObjectInCache o = (ObjectInCache) cacheWrapper.get(path, key); o = new ObjectInCache(Integer.valueOf(o.getVal().intValue() + 1), randStr[taskNumber%randStr.length]); cacheWrapper.put(path, key, o); if (concurrentWrites) { cacheWrapper.endTransaction(true); } long statValue = (System.nanoTime() - startTime); descriptiveStatistics.addValue(statValue); } catch (Throwable e) { log.error("Error appeared whilst writing to cache:" + e.getMessage(), e); try { if (concurrentWrites) { cacheWrapper.endTransaction(false); } } finally { } } finally { logRunCount(taskNumber); } concurrentWrites was set to true. This tests passes nicely in one node (local mode). However in 2,3,4 nodes it fails after first usage of the same object by different node with exception: org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/concurrent/Intermediate-0/Node 0] after [240000] milliseconds for requestor [GlobalTransaction:<10.118.236.212:40325>:0]! Lock held by [GlobalTransaction:<10.118.236.211:8112>:40] at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159) It looks like, in replication the node is not beeing releases after transaction commit. -- 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, 8 months

4
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-1573) Automatically created nodes are not evicted

by Dennis Reed (JIRA)

Automatically created nodes are not evicted ------------------------------------------- Key: JBCACHE-1573 URL: https://jira.jboss.org/jira/browse/JBCACHE-1573 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.1.GA, 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani When parent nodes are created during a put, such as "a" and "b" in: cache.put ( "/a/b/c", "foo", "bar" ); "a" and "b" are never evicted. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1576) Incorrect handling of eviction maxNodes=0 in JBC 3

by Dennis Reed (JIRA)

Incorrect handling of eviction maxNodes=0 in JBC 3 -------------------------------------------------- Key: JBCACHE-1576 URL: https://jira.jboss.org/jira/browse/JBCACHE-1576 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.2.GA Reporter: Dennis Reed Assignee: Dennis Reed JBCACHE-1274 was not fully implemented, missing a few key changes: ExpirationAlgorithm with maxNodes=-1 incorrectly logs a warning of too many nodes (after JBCACHE-1574) FIFOAlgorithm treats maxNodes=0 as unlimited and -1 as 0 LFUAlgorithm javadocs say maxNodes=0 is unlimited LRUAlgorithm treats maxNodes=0 as unlimited MRUAlgorithm treats maxNodes=-1 as 0 -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1574) ExpirationAlgorithm prints excessive (incorrect) WARN logs

by Dennis Reed (JIRA)

ExpirationAlgorithm prints excessive (incorrect) WARN logs ---------------------------------------------------------- Key: JBCACHE-1574 URL: https://jira.jboss.org/jira/browse/JBCACHE-1574 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.2.GA Reporter: Dennis Reed Assignee: Dennis Reed ExpirationAlgorithm prints the following log every time it runs when there is at least one node in its queue, but less than maxNodes: WARN [org.jboss.cache.eviction.ExpirationAlgorithm] (EvictionTimer-0) Unable to remove nodes to reduce region size below 1000. Set expiration for nodes in this region It does *not* print the warning when there actually are more than maxNodes. -- 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, 8 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues April 2010