August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-204) Externalize RegionManager.Capacity parameter

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-204?page=all ] Manik Surtani updated JBCACHE-204: ---------------------------------- Fix Version/s: (was: 2.0.0.GA) > Externalize RegionManager.Capacity parameter > -------------------------------------------- > > Key: JBCACHE-204 > URL: http://jira.jboss.com/jira/browse/JBCACHE-204 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Priority: Minor > Original Estimate: 3 days > Remaining Estimate: 3 days > > RegionManager.CAPACITY is used to determine the size of the eviction event queue. It is fixed now. We should externalize it later such that we can tune the eviction policy performance. E.g., when the load is heavy, we may need to increase the queue size such that it is not blocking. -- 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-706) Integrate JMX bindings of JBoss Cache and PojoCache with AS5 and MC

by Manik Surtani (JIRA)

Integrate JMX bindings of JBoss Cache and PojoCache with AS5 and MC ------------------------------------------------------------------- Key: JBCACHE-706 URL: http://jira.jboss.com/jira/browse/JBCACHE-706 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 This will involve: 1. Adding new JMX MBean interface (is this necessary for the MC? What about standalone use?) 2. Providing sample XML files 3. Updating documentation -- 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
4
0 / 0

[JBoss JIRA] Updated: (JBCACHE-450) Create a pure pojo-based eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ] Manik Surtani updated JBCACHE-450: ---------------------------------- Fix Version/s: (was: 2.0.0.GA) > Create a pure pojo-based eviction policy > ---------------------------------------- > > Key: JBCACHE-450 > URL: http://jira.jboss.com/jira/browse/JBCACHE-450 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Original Estimate: 1 week > Remaining Estimate: 1 week > > The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy as well. -- 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] Updated: (JBCACHE-4) Notification of remote modification

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-4?page=all ] Manik Surtani updated JBCACHE-4: -------------------------------- Fix Version/s: (was: 2.0.0.GA) > Notification of remote modification > ----------------------------------- > > Key: JBCACHE-4 > URL: http://jira.jboss.com/jira/browse/JBCACHE-4 > Project: JBoss Cache > Issue Type: Task > Affects Versions: 2.0.0.GA > Reporter: Bela Ban > Assigned To: Bela Ban > Priority: Minor > Original Estimate: 1 week > Remaining Estimate: 1 week > > TreeCache need to emit a node event that is modify by remote > only, i.e., local modification won't trigger this event. > This event is needed to listen for remote modification when > there is a local copy of this instance around so we know that > it is dirty. Use cases are: http session repl and TreeCacheAop > where after getObject will need a way to know if the underlying > fields have been modified remotely. -- 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] Updated: (JBCACHE-268) PojoCache InternalDelegate can return incorrect AOPInstance object

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-268?page=all ] Manik Surtani updated JBCACHE-268: ---------------------------------- Fix Version/s: (was: 2.0.0.GA) > PojoCache InternalDelegate can return incorrect AOPInstance object > ------------------------------------------------------------------ > > Key: JBCACHE-268 > URL: http://jira.jboss.com/jira/browse/JBCACHE-268 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: PojoCache > Reporter: twundke > Assigned To: Ben Wang > > The getAopInstance(Fqn) method of InternalDelegate currently uses a cache.peek() call to find the AOPInstance object for an FQN. However, I've come across a situation where multiple calls to this method for the same FQN will return different AOPInstance objects. > To be honest, I'm not sure of the exact situation in which this occurs as I haven't delved deep enough. However, the basic idea is that I have an object graph in the cache, all hanging off one particular root-level object. I then do a fairly major addition/update to a number of children, but don't specifically update the root-level object. After this update I find that InternalDelegate returns a new instance of the AOPInstance class for the root object's FQN, which has now lost its POJO reference etc. This in turn forces a re-creation of the root-level object, which loses a number of transient references that I have set. > Note that my object graph has a number of circular references back to this root-level object, so I suspect that the AOP machinery is for some reason updating this object during the update of the children, thereby losing the original AOPInstance reference. > I've put in a quick fix locally that caches references to AOPInstance objects in a HashMap, which follows the idea suggested in the comment for the method. This solves the issue. -- 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] Updated: (JBCACHE-413) Split up build.xml

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-413?page=all ] Manik Surtani updated JBCACHE-413: ---------------------------------- Fix Version/s: (was: 2.0.0.GA) > Split up build.xml > ------------------ > > Key: JBCACHE-413 > URL: http://jira.jboss.com/jira/browse/JBCACHE-413 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Jason T. Greene > Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > buidl.xml is getting too big. Maybe we should split them up, e.g., split the pojo cache portion is a starter. We can do it as JbossAs with import directory. -- 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] Updated: (JBCACHE-30) Multiple MBean Configuration Error

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ] Manik Surtani updated JBCACHE-30: --------------------------------- Fix Version/s: (was: 2.0.0.GA) > Multiple MBean Configuration Error > ---------------------------------- > > Key: JBCACHE-30 > URL: http://jira.jboss.com/jira/browse/JBCACHE-30 > Project: JBoss Cache > Issue Type: Bug > Affects Versions: 1.2 > Reporter: SourceForge User > Assigned To: Ben Wang > > SourceForge Submitter: jiwils . > Some if not all of the JBossCache configuration XML > files contain the following commented MBean definition: >  >  >  >  >  > By uncommenting this MBean definition, I thought I > would get a GUI with which I could inspect the cache, > but instead I got a "multiple MBean" exception. -- 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-1004) Genericize POJO API

by Jason T. Greene (JIRA)

Genericize POJO API ------------------- Key: JBCACHE-1004 URL: http://jira.jboss.com/jira/browse/JBCACHE-1004 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Jason T. Greene Assigned To: Jason T. Greene Fix For: 2.0.0.GA Use generics where possible and logical -- 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
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-3) Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-3?page=all ] Manik Surtani updated JBCACHE-3: -------------------------------- Fix Version/s: (was: 2.0.0.GA) > Expose JGroups (protocols, channel) via JMX, provide common JGroups MBean > ------------------------------------------------------------------------- > > Key: JBCACHE-3 > URL: http://jira.jboss.com/jira/browse/JBCACHE-3 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 2.0.0.GA > Reporter: Bela Ban > Assigned To: Bela Ban > Priority: Minor > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > -- 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] Updated: (JBCACHE-434) InternalDelegate doesn't relocate AOP nodes properly

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ] Manik Surtani updated JBCACHE-434: ---------------------------------- Fix Version/s: (was: 2.0.0.GA) > 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 > 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

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