[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