5 Replies Latest reply on Mar 30, 2006 1:49 AM by Bela Ban

    CacheLoaderInterceptor Bottleneck?

    Paul Smith Newbie

      If our production server requires a restart in peak times, we have noticed incredibly slow throughput in the early minutes after.

      Refering to my comments and thread dumps here:


      I've been looking at the CacheLoaderInterceptor class, and I'm really not sure why there is a synchronized(this) blok in the invoke method with the comment:

      /* On the way in: load elements into cache from the CacheLoader if not yet in the cache. We need to synchronize
      this so only 1 thread attempts to load a given element */

      Well.. err.. if the loading of an element isn't fast (and the reason it's being stored in the cache in the first place is that the lookup is not cheap) then this is going to serialize access to the instance of CacheLoaderInterceptor surely... We'r seeing dozens and dozens of threads blocked waiting for the node to load.

      See the thread dumps attached to the JIRA issue.

      This can't be healthy.. ? Could someone explain why the need to synch on that instance? Isn't the locks on the fqn itself enough?