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

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.