April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-733) Fine-grained JDOM replication effort

by Ben Wang (JIRA)

Fine-grained JDOM replication effort ------------------------------------ Key: JBCACHE-733 URL: http://jira.jboss.com/jira/browse/JBCACHE-733 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: POJOCache This is efforts made to "apectizing" JDOM library under branch JBossCache_1_4_JDOM: 1. Check in additional jdom library: saxpath.jar, jdom.jar, and jaxen-*.jar 2. Re-factored to introduce NonTransient tag. 3. Unit test for jdom -- 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

17 years, 9 months

2
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-625) Serializable POJO to handle object relation as well

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-625?page=all ] Jason T. Greene updated JBCACHE-625: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Serializable POJO to handle object relation as well > --------------------------------------------------- > > Key: JBCACHE-625 > URL: http://jira.jboss.com/jira/browse/JBCACHE-625 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > > When a POJO is Serializable, we used to not support the object relationship. It'd be nice to support it. Idea is the update is corase grained but the object relationship is preserved during replication. We'd create an aop ClassProxy to replace the original Serializable pojo (that is non-primitive). -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-561) Create a separate META-INF sub-directory for PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-561?page=all ] Jason T. Greene updated JBCACHE-561: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Create a separate META-INF sub-directory for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-561 > URL: http://jira.jboss.com/jira/browse/JBCACHE-561 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: 2.0.0.GA > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Separate the PojoCache configuration from regular TreeCache so that user don't get confused. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-674) PojoCache to handle simultaneous pojo attach on the clustering nodes

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-674?page=all ] Jason T. Greene updated JBCACHE-674: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache to handle simultaneous pojo attach on the clustering nodes > -------------------------------------------------------------------- > > Key: JBCACHE-674 > URL: http://jira.jboss.com/jira/browse/JBCACHE-674 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Critical > Fix For: PojoCache 2.2.0 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently we don't handle cases with active attachment of pojo on all clustering nodes. For example, > cacheA.attach("1", pojo1); > cacheB.attach("1", pojo2); > pojo2 will overwrite pojo1 but pojo1 will still have cache interceptor attached to it. So solution will have to be some sort of check dirty mechanism when any POJO operation is called. But this will introduce more overheads. > Still need to gather more use case for this. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-658) Fast locking for mostly-read PojoCache

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-658?page=all ] Jason T. Greene updated JBCACHE-658: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Fast locking for mostly-read PojoCache > -------------------------------------- > > Key: JBCACHE-658 > URL: http://jira.jboss.com/jira/browse/JBCACHE-658 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Nitzan Niv > Assigned To: Jason T. Greene > Fix For: 2.1.0.GA > > > The locking mechanism locks all the nodes in the path from the tree root to the modified node. If the cache contains a deep hierarchy of nodes (e.g., PojoCache that contains complex objects) and the usage of the cache > is mostly-read the locking overhead is unnecessarilly large. > To enable REPEATABLE_READ isolation level with minimal overhead (but with reduced update parallelism) just the tree root should be locked instead of the nodes-path. To define this policy as a new isloation level ("single"): > Change in PessimisticLockInterceptor (line 199): > else { > if(isolation_level == IsolationLevel.SINGLE) {//XXX > if (i == 0) { > acquired=child_node.acquire(owner, lock_timeout, lock_type); > } > } else { > if(lock_type == DataNode.LOCK_TYPE_WRITE && i == (treeNodeSize - 1)) { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_WRITE); > } > else { > acquired=child_node.acquire(owner, lock_timeout, DataNode.LOCK_TYPE_READ); > } > }//XXX > } > in LockStrategyFactory.java: > if (lockingLevel == IsolationLevel.REPEATABLE_READ || lockingLevel == IsolationLevel.SINGLE) //XXX > return new LockStrategyRepeatableRead(); > and add the "SINGLE" isolation level to IsolationLevel.java. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-172) Strange performance problem with LRU

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-172?page=all ] Jason T. Greene updated JBCACHE-172: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Strange performance problem with LRU > ------------------------------------ > > Key: JBCACHE-172 > URL: http://jira.jboss.com/jira/browse/JBCACHE-172 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.2 > Environment: Windows XP > Eclipse 3.1 > JDK50 > Reporter: Peter Bridge > Assigned To: Jason T. Greene > Priority: Minor > Fix For: 2.0.0.GA > > Attachments: CachePerformanceTest.java, treecacheconfig.xml > > > There seems to be a performance issue when using the LRU option. With the attaches test, the 100,000 item Get takes 1200ms with LRU and 800ms without any config loaded. I also noticed the put is slower. > get, put, remove > 2704 1187 625 configured > 2204 812 625 not configured > For comparison I used a LinkedHashMap configured as LRU and get these figures: > 1370 184 172 > Is this an issue with my configuration? Or a problem with how I'm using the cache? -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-977) PojoCache annotated50 run.loadtime.example failed

by Ben Wang (JIRA)

PojoCache annotated50 run.loadtime.example failed ------------------------------------------------- Key: JBCACHE-977 URL: http://jira.jboss.com/jira/browse/JBCACHE-977 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: PojoCache Affects Versions: 1.4.1.SP1 Reporter: Ben Wang Assigned To: Ben Wang Fix For: PojoCache Reported by a user. The root cause seems to be in jboss aop since it fails when a subclass (in this Student from Person) is put into PojoCache and instrumented during loadtime (note that compile mode works correctly). I have checked PojoCache2.0. It works fine there with jboss aop 2.0. I ahve checked in an example in NewReplicatedAopTest. Will have Kabir take a look. -- 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

17 years, 9 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-288) Enable garbage collection for Pojo under cache management

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-288?page=all ] Jason T. Greene updated JBCACHE-288: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > Enable garbage collection for Pojo under cache management > --------------------------------------------------------- > > Key: JBCACHE-288 > URL: http://jira.jboss.com/jira/browse/JBCACHE-288 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Fix For: PojoCache > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, once the pojo is put into cache, it won't get gced unless user specifically issues removeObject. There is eviction policy. However, it is coupled with cache loader so the object is still around for a specific time span. We should come up with a way to gc these pojos properly. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-741) Create a jdom replication GUI example

by Ben Wang (JIRA)

Create a jdom replication GUI example ------------------------------------- Key: JBCACHE-741 URL: http://jira.jboss.com/jira/browse/JBCACHE-741 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library. -- 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

17 years, 9 months

2
10
0 / 0

[JBoss JIRA] Updated: (JBCACHE-585) PojoCache Collection class when detached, the in-memory fields are not updated

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-585?page=all ] Jason T. Greene updated JBCACHE-585: ------------------------------------ Assignee: Jason T. Greene (was: Ben Wang) > PojoCache Collection class when detached, the in-memory fields are not updated > ------------------------------------------------------------------------------ > > Key: JBCACHE-585 > URL: http://jira.jboss.com/jira/browse/JBCACHE-585 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Fix For: PojoCache 2.1.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > This happens during the refactoring of Collections class (JBCACHE-580). For speed reason, I choose not to update it now. But we can make it configurable for performance optimization. -- 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

17 years, 9 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 April 2007