[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails

[Ben Wang (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBCACHE-710?page=comments#action_12345897 ] 
            
Ben Wang commented on JBCACHE-710:
----------------------------------

This problem arises during development where there are all sorts of exception conditions and resboot of the AS leaves the .dat file in bad state. Next time around, the recursive loop occurs. This doesn't happen often but is deadly nonetheless.

Since I only test the file cache loader so I can't say for the rest. But I think it is a good idea anyway to throw "DataNotRemovedException" as a runtime exception to alert the user of this problem.

> 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