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

On 24 Nov 2008, at 17:45, Brian Stansberry wrote: > 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? Makes sense. See https://jira.jboss.org/jira/browse/JBCACHE-1446

> > > [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