March 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Commented: (JBCACHE-1236) Non-blocking state transfer

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1236?page=com.atlassian.jira.p... ] Manik Surtani commented on JBCACHE-1236: ---------------------------------------- MVCC is mandatory, as is STREAMING_STATE_TRANSFER in JGroups Enabled by using Configuration.setUseNonBlockingStateTransfer() or <stateRetrieval nonBlocking="true" /> > Non-blocking state transfer > --------------------------- > > Key: JBCACHE-1236 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1236 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Critical > Fix For: 3.1.0.BETA1, 3.1.0.GA > > > See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheNewStateTransfer -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1236) Non-blocking state transfer

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1236?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1236. ------------------------------------ Resolution: Done > Non-blocking state transfer > --------------------------- > > Key: JBCACHE-1236 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1236 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Replication > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Critical > Fix For: 3.1.0.BETA1, 3.1.0.GA > > > See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheNewStateTransfer -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1498) Option for fair locking in MVCC

by Krzysztof Sobolewski (JIRA)

Option for fair locking in MVCC ------------------------------- Key: JBCACHE-1498 URL: https://jira.jboss.org/jira/browse/JBCACHE-1498 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.0.3.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: fair-locking.patch The javadoc for OwnableReentrantLock says: * For the sake of performance, this lock only supports nonfair queueing. Well, I understand the sentiment, but starvation can be quite a problem with nonfair locking. So I implemented an option to swith to fair locking (patch attached). Please review :) -- 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, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1496) Typo in ReadCommittedNode.Flags.ORIG_CHILDREN_LOADED enum mask

by Krzysztof Sobolewski (JIRA)

Typo in ReadCommittedNode.Flags.ORIG_CHILDREN_LOADED enum mask -------------------------------------------------------------- Key: JBCACHE-1496 URL: https://jira.jboss.org/jira/browse/JBCACHE-1496 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.3.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani I'm a little hesitant to report this because it looks like a brown paper bag material :) The mask for ReadCommittedNode.Flags.ORIG_CHILDREN_LOADED enum constant should be 0x10 (hex), not 0x16. Or just 16 :) -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1494) Lock-per-Fqn option in addition to lock striping, for MVCC

by Manik Surtani (JIRA)

Lock-per-Fqn option in addition to lock striping, for MVCC ---------------------------------------------------------- Key: JBCACHE-1494 URL: https://jira.jboss.org/jira/browse/JBCACHE-1494 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.0.3.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0.GA Lock striping, while performant and memory efficient, can lead to deadlocks in certain cases where several fqns map to the same lock. An alternative where a lock er fqn is used may be desirable. -- 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, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1493) REPEATABLE_READ inconsistent with write skew disabled

by Manik Surtani (JIRA)

REPEATABLE_READ inconsistent with write skew disabled ----------------------------------------------------- Key: JBCACHE-1493 URL: https://jira.jboss.org/jira/browse/JBCACHE-1493 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.0.3.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0.GA Inconsistent in that with a put(), we have the last tx winning and overwriting state, which is allowed if write skew is disabled. If we have a concurrent put() and removeNode(), this is a problem since the removeNode() would only remove a node read earlier in the same transaction and not the new, updated node. E.g.,: cache.put("/a", "k", "v"); tx.begin(); cache.get("/a"); tx.suspend(); cache.put("/a", "k", "v2"); tx.resume(); cache.removeNode("/a"); tx.commit(); // node still exists!! -- 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, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1492) Add a hasChildren() (or equivalent) method to the Node interface

by Nathan Messer (JIRA)

Add a hasChildren() (or equivalent) method to the Node interface ---------------------------------------------------------------- Key: JBCACHE-1492 URL: https://jira.jboss.org/jira/browse/JBCACHE-1492 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Nathan Messer Assignee: Manik Surtani Fix For: 3.1.0.GA We would like to request a hasChildren() (or some equivalent) method on the Node interface to establish if a node has children. The NodeSPI interface already has a hasChildrenDirect() method, which is the functionality we are looking for. The main reason for wanting a hasChildren() method, rather than just getting the children, or the children names, and checking the length is performance. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1449) Small lock confusion in CacheLoaderInterceptor

by Krzysztof Sobolewski (JIRA)

Small lock confusion in CacheLoaderInterceptor ---------------------------------------------- Key: JBCACHE-1449 URL: https://jira.jboss.org/jira/browse/JBCACHE-1449 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani I was doing another torture-test of one of my components based on JBoss Cache and noticed mysterious "can't lock node" exceptions. The test is very simple: 5 threads are trying to retrieve one node's key, 5 other threads try to delete it. Long story short, I think the result is one the smallest fixed I've ever seen :) Index: src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java =================================================================== --- src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (revision 6986) +++ src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (working copy) @@ -245,7 +245,7 @@ { NodeSPI n = dataContainer.peek(fqn, true, true); Object lockOwner = lockManager.getLockOwner(ctx); - boolean needLock = n != null && !lockManager.ownsLock(fqn, lockOwner); + boolean needLock = n != null && !lockManager.ownsLock(n, lockOwner); boolean mustLoad = false; try { It seems that when the node (n) is deleted, the lockManager checks some different nodes map, when it uses the node's FQN, than is later checked on line 252, where it tries to read-lock the node (and fails, because it's already locked by pessimistic locking interceptor). -- 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, 9 months

2
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-1489) Javadocs not clear on how to create basic local mode caches

by Manik Surtani (JIRA)

Javadocs not clear on how to create basic local mode caches ----------------------------------------------------------- Key: JBCACHE-1489 URL: https://jira.jboss.org/jira/browse/JBCACHE-1489 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.3.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.1.0.GA Could also help by making default config bundles, like Configuration.getDefaultLocalConfig(), getDefaultReplicatedConfig(), etc. >From Bill Burke, who reported this: " Problem: This code did not work: CacheFactory factory = new DefaultCacheFactory(); ExpirationAlgorithmConfig exp = new ExpirationAlgorithmConfig(); exp.setMaxNodes(maxSize); EvictionRegionConfig evictionRegionConfig = new EvictionRegionConfig(); evictionRegionConfig.setEvictionAlgorithmConfig(exp); EvictionConfig evictConfig = new EvictionConfig(); evictConfig.setDefaultEvictionRegionConfig(evictionRegionConfig); evictConfig.setWakeupInterval(wakeupInterval); Configuration config = new Configuration(); config.setCacheMode(Configuration.CacheMode.LOCAL); config.setEvictionConfig(evictConfig); I got a NullPointerException at line 700 of RegionManagerImpl. This is because I did not set the region FQN within the EvictionRegionConfig constructor. There is no documentation to figure out how to do this. I had to dig into source code to figure out the problem. Also javadocs are not clear on what the default values are or how to assemble things. " -- 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, 9 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-772) State transfer not handled properly in case of reconnect

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-772?page=com.atlassian.jira.pl... ] Manik Surtani updated JBCACHE-772: ---------------------------------- Fix Version/s: 3.2.0.GA (was: 3.1.0.GA) > State transfer not handled properly in case of reconnect > -------------------------------------------------------- > > Key: JBCACHE-772 > URL: https://jira.jboss.org/jira/browse/JBCACHE-772 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.GA, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.GA, 1.4.0.SP1 > Reporter: Brian Stansberry > Assignee: Manik Surtani > Fix For: 3.2.0.GA > > > In createService(), TreeCache set Channel.AUTO_GET_STATE to true. This should only be done if the cache is configured to do an initial state transfer. > That's easy to fix. What's harder to fix is what to do when region-based marshalling is in effect. Probably, something like the following: > 1) In viewAccepted, monitor for the case where a view is issue that doesn't include the current node. Set a flag and ??? (throw exceptions when attempts are made to use the cache???) > 2) When another view is accepted that once again includes the current node, iterate through the various marshalling regions, inactivating and then reactivating them (reactivation will cause a partial state transfer). -- 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues March 2009