[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
17 years, 6 months
[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
17 years, 6 months
[JBoss JIRA] Updated: (JBCACHE-224) Expose eviction management attributes
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-224?page=all ]
Manik Surtani updated JBCACHE-224:
----------------------------------
Fix Version/s: (was: 2.0.0.GA)
> Expose eviction management attributes
> -------------------------------------
>
> Key: JBCACHE-224
> URL: http://jira.jboss.com/jira/browse/JBCACHE-224
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Ben Wang
> Assigned To: Ben Wang
> Priority: Minor
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We will need to expose the eviction side of management attributes. This is useful for troubleshooting. But keep in mind that it can also depends on the evction policy used as well. Basic ones are:
> 1. How long does the eviction thread take to process the eviction each time? Or the aevergage time?
> 2. What is the current capacity for the event queue?
> 3. How many nodes have been evicted for this wakeup interval and what's the average time it takes?
> 4. How many eviction miss? I.e., try to evict but the node is gone?
--
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, 6 months