April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-758) Move RuleModel (ROM) to compiler

by Michael Neale (JIRA)

Move RuleModel (ROM) to compiler -------------------------------- Key: JBRULES-758 URL: http://jira.jboss.com/jira/browse/JBRULES-758 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-876) Region marker in region-based marshalling message should be region fqn

by Brian Stansberry (JIRA)

Region marker in region-based marshalling message should be region fqn ---------------------------------------------------------------------- Key: JBCACHE-876 URL: http://jira.jboss.com/jira/browse/JBCACHE-876 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 1.4.1.GA When region based marshalling is used, the replication message first has a serialized Fqn to identify the region, followed by a separately serialized method call. Receiver deserializes the identifier fqn and uses it to find the classloader to use to deserialize the main message. Problem is the region identifier Fqn is the full Fqn of a node. This prevents the use in Fqns of classes that require the custom classloader to deserialize. This can be mitigated by changing the marker Fqn to simply identify the Region, not some subnode. Now the restriction on use of custom classes is limited to the region Fqn; portions of Fqns below the region level can be of any serializable class. This is needed to solve JBCLUSTER-150. Downside is the node marshalling the message now needs to do a Region lookup to get the region Fqn. Upsides are a reduced message size, since the shorter region fqn is marshalled, as well as a possibly faster region lookup time on the recipient nodes, since extraneous data can be ignored. -- 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

19 years, 3 months

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

19 years, 3 months

1
0
0 / 0

[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

19 years, 3 months

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

19 years, 3 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

19 years, 3 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

19 years, 3 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

19 years, 3 months

1
0
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

19 years, 3 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

19 years, 3 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007