[JBoss JIRA] Created: (JBCACHE-1149) FIFOPolicy is adding a visited node to the evictionqueue
by Maddulety Vankadara (JIRA)
FIFOPolicy is adding a visited node to the evictionqueue
--------------------------------------------------------
Key: JBCACHE-1149
URL: http://jira.jboss.com/jira/browse/JBCACHE-1149
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Eviction
Affects Versions: 2.0.0.CR2
Environment: OS: WIn XP SP2; JBOSS AS: 4.0.3; Cache : 2.0.0CR2
Reporter: Maddulety Vankadara
Assigned To: Manik Surtani
Created Eviction Policy with the following config:
<attribute name="EvictionPolicyConfig">
<config>
<attribute name="wakeUpIntervalSeconds">30</attribute>
<attribute name="eventQueueSize">200000</attribute>
<!-- Cache wide default -->
<region name="/_default_" policyClass="org.jboss.cache.eviction.FIFOPolicy">
<attribute name="maxNodes">500</attribute>
</region>
</config>
</attribute>
And then created a region programmatically and assigned FIFOPolicy to that region.
FIFOConfiguration evictionConfig = new FIFOConfiguration();
evictionConfig.setMaxNodes(CacheConstants.60);
Region rn = getCache().getRegion(Fqn.fromString("\a\b\c"), true);
rn.setEvictionPolicy(evictionConfig);
Add some nodes under "/a/b/c". All nodes are added to the evictionqueue properly.
But when I traverse the region /a/b/c, This node is also added to the evictionqueue and when the queue reaches the limit "MAXNodes"( which is 60 here), the node /a/b/c is evicted from cache.
I think a visted node should not be evicted in a FIFO policy.
After going through the code, I noticed that VISIT_NODE_EVENT is not ignored in the FIFOPolicy class.
Overriding the bemow method in org.jboss.cache.eviction.FIFOPolicy will fix the issue:
public boolean canIgnoreEvent(Fqn fqn, NodeEventType eventType) {
return (eventType == NodeEventType.VISIT_NODE_EVENT);
}
--
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
[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
by Ben Wang (JIRA)
CacheLoader passivation/activation produces recursive exception when loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway).
--
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
[JBoss JIRA] Created: (JBCACHE-833) Redundant lock in cache loader
by Ben Wang (JIRA)
Redundant lock in cache loader
------------------------------
Key: JBCACHE-833
URL: http://jira.jboss.com/jira/browse/JBCACHE-833
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0.SP1, 1.4.0.GA
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Minor
Fix For: 2.0.0.GA
Currently in CacheLoader, it calls "lock" from loadIfNeeded method. The "lock" method in turns invokes
TreeCache.java
public void _lock(Fqn fqn, DataNode.LockType lock_type, boolean recursive)
throws TimeoutException, LockingException
{
log.warn("method _lock() should not be invoked on TreeCache");
}
I think the LockInterceptor should take care of the locking properly. So this call should be deprecated.
--
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