[jboss-jira] [JBoss JIRA] Created: (JBAS-4611) HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns

Galder Zamarreno (JIRA) jira-events at lists.jboss.org
Thu Aug 16 03:58:01 EDT 2007


HTTP Session Repl Cache configured with CacheLoader can cause slow AS shutdowns
-------------------------------------------------------------------------------

                 Key: JBAS-4611
                 URL: http://jira.jboss.com/jira/browse/JBAS-4611
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, JBoss Cache, Web (Tomcat) service
    Affects Versions: JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry
            Priority: Minor


When AS stops, the sessions for that web app are evicted from memory, 
which means removing from the memory locally. We still need the sessions
 in other nodes, for example if we're bringing a node down for maintenance 
in which case, we don't want to remove sessions of the cluster completely. 
We want users to failover to another node and continue as normal.

The code handling this evictions first removes any data in these sessions and
 then tries to check whether this HTTP session has any children nodes in the
 cache so that it can do a complete clearout of the subtree:

JBossCacheWrapper:

   void evictSubtree(Fqn fqn)
   {

      Exception ex = null;
      for (int i = 0; i < RETRY; i++)
      {
         try
         {
            // Evict the node itself first, since if it stores a Pojo
            // that will do everything
            proxy_.evict(fqn);

            // next do a depth first removal; this ensure all nodes
            // are removed, not just their data map
            Set children = proxy_.getChildrenNames(fqn);
...

If no cache loaders were used, this would be fine, it wouldn't find any 
children in memory and would return quickly. A true local call. 
However, for a customer who's using a ClusteredCacheLoader to get around 
some state transfer issues, when AS discovers that this session does 
not contain any children nodes, it goes remote to find them because 
it didn't find them locally (won't find them remotely either):

CacheLoaderInterceptor:

   private boolean mustLoad(DataNode n, Object key)
   {
      return n == null ||
              (n.containsKey(TreeCache.UNINITIALIZED) && (key == null || !n.containsKey(key)));
   }

As the node has been emptied, CLI (CacheLoaderInterceptor) thinks it 
needs to go remote. Same thing would happen with Pojo too (as the 
entire node is emptied). This is an unnecessary trip which is delaying 
the local eviction of sessions.

This would happen regardless of the CacheLoader used.

Two possible solutions come to my mind:
- easy one: call getChildrenNames() before evict and cache in a local variable the 
children Set. getChildrenNames() would land locally cos the fqn exists yet.
- complex one: do a getChildrenNames(Option) passing an option indicating that 
if the lookup fails locally, don't bother going remote.

-- 
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

        



More information about the jboss-jira mailing list