August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-584) Investigate use of lazy mapping for PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-584?page=all ] Ben Wang updated JBCACHE-584: ----------------------------- Fix Version/s: PojoCache 2.2.0 (was: PojoCache) > Investigate use of lazy mapping for PojoCache > --------------------------------------------- > > Key: JBCACHE-584 > URL: http://jira.jboss.com/jira/browse/JBCACHE-584 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.2.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Recent perf test on PojoCache shows bottleneck is on the initial mapping of putObject causing numerous trips to the local cache store. To optimize it further, either the TreeCache local mode need to be enhanced. Or one solution to this is the use of lazy mapping of the pojo. For example, when putObject is called, pojo is not mapped. Instead, it is stored under a "Serialized" state (can use JBossSerialization if pojo is not even Seriailizable) first. Then when the field is modified (detected from the CacheInterceptor), we will then map it lazily to the PojoCache store. > The performance gain can be had, if 1) initial saving of mapping, 2) field update is only selected. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-589) PojoCache pojo level locking semantics

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-589?page=all ] Ben Wang updated JBCACHE-589: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > PojoCache pojo level locking semantics > -------------------------------------- > > Key: JBCACHE-589 > URL: http://jira.jboss.com/jira/browse/JBCACHE-589 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > > When using pessimistic locking, we need to provide a pojo level locking semantics. Current one uses only node level and there is big problem when the node is not yet exist since we can't lock it that way. Idea maybe to provide an extra lock interceptor that tracks the pojo-level locking. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-434) InternalDelegate doesn't relocate AOP nodes properly

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ] Ben Wang updated JBCACHE-434: ----------------------------- Fix Version/s: 2.0.0 (was: PojoCache) > InternalDelegate doesn't relocate AOP nodes properly > ---------------------------------------------------- > > Key: JBCACHE-434 > URL: http://jira.jboss.com/jira/browse/JBCACHE-434 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1 > Reporter: twundke > Assigned To: Ben Wang > Fix For: 2.0.0 > > Attachments: relocate.txt > > > When the object graph handler attempts to remove a node that has references to it, it relocates the data to the first referencing FQN in the list. However, InternalDelegate.relocate() fails to correctly update the AOP references. There is some commented-out code that seems to attempt to update the indirect FQN. > I've attatched my updated code (for our demo), but it's overly complicated due to lack of time, sleep etc. In fact it fully updates the internal state of the cache for the node (including changing the indirect FQN, and changing all references to point to the new indirect FQN), which was the quickest way to get a solution at the time. You can probably cut out half of this by simply updating the indirect FQN correctly, which I presume was the intent in the first place. However, I believe this still only half-solves the problem as the reference counts need to be updated. > Sorry if this is a bit of a vague bug report Ben, but I can't fully remember my thinking at the time. Hopefully my code at least shows all that has to be done to keep the cache consistent. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-518) Investigate use a new replication schema for PojoCache

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-518?page=all ] Ben Wang updated JBCACHE-518: ----------------------------- Fix Version/s: PojoCache 2.2.0 (was: PojoCache) > Investigate use a new replication schema for PojoCache > ------------------------------------------------------ > > Key: JBCACHE-518 > URL: http://jira.jboss.com/jira/browse/JBCACHE-518 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.2.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We should look into a new replication schema for PojoCache putObject and removeObject operation. Idea is during replication, instead of breaking it down and do lots of puts, we replicate the original objects and map it into PojoCache on the other side. This has potential of saving the binary size but has pontential to be more cpu intensive. > The other issue is what to do with automicity during putObject and removeObject? -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-327) Expose PojoCache management attribtues

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-327?page=all ] Ben Wang updated JBCACHE-327: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) Assignee: Ben Wang (was: Bela Ban) > Expose PojoCache management attribtues > -------------------------------------- > > Key: JBCACHE-327 > URL: http://jira.jboss.com/jira/browse/JBCACHE-327 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.1.0 > > Original Estimate: 4 weeks > Remaining Estimate: 4 weeks > > We need to expose JBossCacheAop management attributes. Here are some thoughts: > - # of pojos > - Pojo references > - pojo lifetime > - pojo evicted > - pojo life cycle listener (field access) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-281) PojoCahce initialize "aspectized" pojos when first retrieved

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-281?page=all ] Ben Wang updated JBCACHE-281: ----------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) > PojoCahce initialize "aspectized" pojos when first retrieved > ------------------------------------------------------------ > > Key: JBCACHE-281 > URL: http://jira.jboss.com/jira/browse/JBCACHE-281 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: PojoCache 2.1.0 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Currently, when we do getObject for the first time, we don't initialize the "aspectized" pojo after a get/set is requested. As a result, some of the fields will be un-initialized untill after they are accessed. > We need to provide an option to actively initialize the pojos. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-13) Lazy loading: PojoCache and CacheLoader

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-13?page=all ] Ben Wang updated JBCACHE-13: ---------------------------- Fix Version/s: PojoCache 2.1.0 (was: PojoCache) > Lazy loading: PojoCache and CacheLoader > --------------------------------------- > > Key: JBCACHE-13 > URL: http://jira.jboss.com/jira/browse/JBCACHE-13 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 1.2.4SP1 > Reporter: Bela Ban > Assigned To: Ben Wang > Priority: Critical > Fix For: PojoCache 2.1.0 > > Original Estimate: 3 weeks > Remaining Estimate: 3 weeks > > Idea is to have a configurable option that can be set either to eager or lazy loading. This can apply to whether it is with or without cache loader as well. For example, we may as well do the initial mapping lazily. > Example: > Person p = cache.getObject("/person"); > p.getName(); only primitive fields get loaded (not Address, e.g.) -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-60) Packaging standalone tc5 http session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-60?page=all ] Brian Stansberry updated JBCLUSTER-60: -------------------------------------- Fix Version/s: Q1Y7 (was: Q4Y6) > Packaging standalone tc5 http session replication using JBossCache > ------------------------------------------------------------------ > > Key: JBCLUSTER-60 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-60 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Brian will own 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-13) Standalone Tomcat http session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-13?page=all ] Brian Stansberry updated JBCLUSTER-13: -------------------------------------- Fix Version/s: Q1Y7 (was: Q4Y6) > Standalone Tomcat http session replication using JBossCache > ----------------------------------------------------------- > > Key: JBCLUSTER-13 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-13 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q1Y7 > > Original Estimate: 5 weeks > Remaining Estimate: 5 weeks > > Porting the current http session replication implementation to Tomcat standalone. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-112) WL http session repl using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-112?page=all ] Brian Stansberry updated JBCLUSTER-112: --------------------------------------- Fix Version/s: Q1Y7 (was: Q4Y6) > WL http session repl using JBossCache > ------------------------------------- > > Key: JBCLUSTER-112 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-112 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Fix For: Q1Y7 > > > WL http session fine-grained replication using JBossCache > Goal: > To use one single pluggable JBoss web clustering module to run JBoss, Tomcat (standalone), and Weblogic http session replication. Right now, both JBoss and Tomcat standalone has used the same module to perform session replication. Currently, we have options of using different replication granularity: SESSION, ATTRIBUTE, and FIELD where FIELD is the fine-grained replication using TreeCacheAop (aka POJO Cache). What is left is Weblogic one. Although Weblogic has itself a replication layer, use of JBossCache is still attractive because no expensive clustering licensing is needed! > Possible steps need to be done: > 1. Weblogic has an option of allowing a user to specify a session persistence manager (to file, e.g.). This is where other caching solutions used to hook into WL. We should do the same using JBossCache. However, the exact steps need to be determined. > 2. Determine the necessary Manager interface that is needed to unify all 3 solutions. Currently, both in JBoss and Tomcat, we have a notion of Manager and Session interface. Session should be relatively standard. But Manager is Tomcat specific. We will need to investigate on the possibility for extension. > 3. Tomcat uses Valve to create the replication trigger. Need to find a way to do that in WL. How about filter? > 4. Determine the necessary configuration. Currently in JBoss, we allow to have useJK flag for mod_jk specific failover. Solution in WL should work the same. And so is the session replication granularity. > 5. JBossCache startup. Weblogic has a startup class that should allow JBossCache to start up as a singleton and for later lookup. Under JBoss, JBossCache is run as a MBean. > 6. Management attributes. Currently, we are developing JBoss Cache JMX attribute management in 1.3. We will also need to add http session replication management layer as well to be used by all 3 solutions. > 7. Performance benchmarking. When it is completed, we will need to conduct extensive benchmarking. -- 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, 11 months

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