August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBCACHE-546) Move lock related operations to a separate utility, such as NodeLock

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-546?page=all ] Manik Surtani closed JBCACHE-546. --------------------------------- Fix Version/s: (was: 2.0.0.GA) (was: 2.0.0.ALPHA2) Resolution: Rejected > Move lock related operations to a separate utility, such as NodeLock > -------------------------------------------------------------------- > > Key: JBCACHE-546 > URL: http://jira.jboss.com/jira/browse/JBCACHE-546 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > > This is to reduce the amount of methods in Node to keep them fairly succinct. > The lock in a Node itself could be package-protected so that interactions must happen through this class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-543) Consider synchronized(this) instead of a separate lock

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ] Manik Surtani closed JBCACHE-543. --------------------------------- Fix Version/s: (was: 2.0.0.GA) (was: 2.0.0.ALPHA2) Resolution: Rejected > Consider synchronized(this) instead of a separate lock > ------------------------------------------------------ > > Key: JBCACHE-543 > URL: http://jira.jboss.com/jira/browse/JBCACHE-543 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > > This will save one object per node, not a big deal but something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-885) Bug when calling putObject() with array as argument

by Bela Ban (JIRA)

Bug when calling putObject() with array as argument --------------------------------------------------- Key: JBCACHE-885 URL: http://jira.jboss.com/jira/browse/JBCACHE-885 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Reporter: Bela Ban Assigned To: Ben Wang Should at least not lead to an exception, we could for example state that we don't support arrays yet. To reproduce: TreeCacheAop cache; long arr=new long[]{1,2}; cache.putObject("arr", arr); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

3
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-806) Invalidation causes problems with otimistic data versioning and certain edge cases

by Manik Surtani (JIRA)

Invalidation causes problems with otimistic data versioning and certain edge cases ---------------------------------------------------------------------------------- Key: JBCACHE-806 URL: http://jira.jboss.com/jira/browse/JBCACHE-806 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.0.SP1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 Related to JBCACHE-793, but that has more to do with fixing the recommended configurations. >From email conversations: Manik >> At the moment, if I do a put() with V1 into CacheA, this sends an invalidation msg to CacheB. If CacheB has V2 already, the invalidation will fail. What you are saying is, this failure should propagate back to CacheA so the put() with V1 will also fail and this will not exist in CacheA's memory. Am I correct? Max >> It wasn't the scenario I had in mind, but this one is probably also relevant. Manik >> Or is the scenario you're trying to paint more like: V2 put into CacheA. CacheB has V1, gets the invalidation msg, and V1 is evicted. Someone now calls a put() on CacheB with V1, and you are afraid this will be written into the cache? This is true, the invalidation back to CacheA will fail, but CacheB will have stale data in the cache. Max >> This is the scenario I had in mind yes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

2
14
0 / 0

[JBoss JIRA] Created: (JBCACHE-912) Fix tutorial

by Manik Surtani (JIRA)

Fix tutorial ------------ Key: JBCACHE-912 URL: http://jira.jboss.com/jira/browse/JBCACHE-912 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.1.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

4
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-739) Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders

by shimi k (JIRA)

Exception in a CacheLoader throws ChainingCacheLoader calling method and prevent the call to the next CacheLoaders ------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-739 URL: http://jira.jboss.com/jira/browse/JBCACHE-739 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0 Reporter: shimi k Assigned To: Manik Surtani Fix For: 2.0.0 All the delegate methods in ChainingCacheLoader throws Exceptions. Each one of the methods iterates on all the configured Cacheloader. public void put(Fqn name, Map attributes) throws Exception { Iterator i = writeCacheLoaders.iterator(); while (i.hasNext()) { CacheLoader l = (CacheLoader) i.next(); l.put(name, attributes); } } Since the methods throws an Exception, Exception in one of the CacheLoaders will throw the thread out of the method. If the Exception will happen before the last CacheLoader, the ChainingCacheLoader will not call the other CachLoaders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

3
7
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-996) Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-996?page=all ] Manik Surtani reopened JBCACHE-996: ----------------------------------- Assignee: (was: Manik Surtani) > Test failure - org.jboss.cache.multiplexer.BuddyGroupAssignmentTest > ------------------------------------------------------------------- > > Key: JBCACHE-996 > URL: http://jira.jboss.com/jira/browse/JBCACHE-996 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.BETA1 > Reporter: Rajesh Rajasekaran > Fix For: 2.0.0.BETA2 > > > org.jboss.cache.multiplexer.BuddyGroupAssignmentTest fails on the release distribution. > To reproduce: > run ./build.sh dist. > Unzip JBossCache-all-2.0.0.BETA1.zip > Run ant one.test -Dtest=org.jboss.cache.multiplexer.BuddyGroupAssignmentTest > <testcase classname="org.jboss.cache.multiplexer.BuddyGroupAssignmentTest" name="testRemovalFromCluster2Buddies" time="24.523"> > <failure message="10.16.7.254:60612 should be a buddy to 10.16.7.254:60606" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: 10.16.7.254:60612 should be a buddy to 10.16.7.254:60606 > at org.jboss.cache.buddyreplication.BuddyReplicationTestsBase.assertIsBuddy(BuddyReplicationTestsBase.java:285) > at org.jboss.cache.buddyreplication.BuddyGroupAssignmentTest.testRemovalFromCluster2Buddies(BuddyGroupAssignmentTest.java:131) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > </failure> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-553) JBossCache throughput II

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ] Manik Surtani reopened JBCACHE-553: ----------------------------------- Assignee: (was: Manik Surtani) > JBossCache throughput II > ------------------------ > > Key: JBCACHE-553 > URL: http://jira.jboss.com/jira/browse/JBCACHE-553 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Fix For: 2.0.0.GA > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive. > The load condition are: > 400 clients (total), no sleep, 7kbyte payload > async: > Cluster size, throughtput (req/sec) > 8, 1270 (8.9MB/sec) > 4, 1270 > 2, 1400 > sync: > Cluster size, throughtput (req/sec) > 8, 432 (3.0MB/sec) > 4, 480 > 2, 700 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-562) Disable cache loader when no cacheloader class is specified

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ] Manik Surtani reopened JBCACHE-562: ----------------------------------- Assignee: (was: Manik Surtani) > Disable cache loader when no cacheloader class is specified > ----------------------------------------------------------- > > Key: JBCACHE-562 > URL: http://jira.jboss.com/jira/browse/JBCACHE-562 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Priority: Minor > Fix For: 2.0.0.GA > > > In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBCACHE-543) Consider synchronized(this) instead of a separate lock

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-543?page=all ] Manik Surtani reopened JBCACHE-543: ----------------------------------- Assignee: (was: Manik Surtani) > Consider synchronized(this) instead of a separate lock > ------------------------------------------------------ > > Key: JBCACHE-543 > URL: http://jira.jboss.com/jira/browse/JBCACHE-543 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Fix For: 2.0.0.GA, 2.0.0.ALPHA2 > > > This will save one object per node, not a big deal but something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2007