[jbosscache-dev] Optimize use of CacheLoader.exists() with passivation

[Brian Stansberry]

I've been profiling JBoss AS web session replication, and one of the 
significant hits I'm seeing is from calls to File.exists() from 
FileCacheLoader (see attached).  In turn, those calls are due calls from 
LegacyActivationInterceptor, particularly the 
removeNodeFromCacheLoader() method, which is called with every 
invocation.[1]  Many of these calls are on the most critical path[2] so 
speeding them can have large implications for overall cluster performance.

I'm wondering if we can be smarter here and avoid most calls to 
removeNodeFromCacheLoader()?

Is it a correct statement that, logically, with passivation the only 
time it would make sense to remove a node from the cache loader is if 
that invocation loaded data from the cache loader?  The node remove is 
allowed because the in-memory data has become complete; the only way 
previously incomplete data can become complete is if a request has 
loaded data.  So, if we can pass back to the activation interceptor info 
on whether a load has occurred (e.g. via a simple boolean flag in 
InvocationContext), we can avoid most calls to CacheLoader.exists().

Thoughts?

[1] ActivationInterceptor would have the same problem if I were using MVCC.
[2] Up calls from JGroups. NAKACK only allows one such call per peer at 
a time, and FC blocks web request threads based on the handling of these 
calls, so the speed of these calls is the most critical path in the 
whole system.

-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: websessreplhotspots.png
Type: image/png
Size: 137333 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20081124/be35e82b/attachment.png