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

[Jimmy Wilson (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-4611?page=comments#action_12375148 ] 
            
Jimmy Wilson commented on JBAS-4611:
------------------------------------

Using a local remove in evictSubTree seems to work as expected.

> 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: Web (Tomcat) service, Clustering, JBoss Cache
>    Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.2.1.GA, JBossAS-5.0.0.Beta2
>            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