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

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(a)redhat.com < websessreplhotspots .png>_______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev