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: http://jira.jboss.com/jira/browse/JBCACHE-512 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? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3933276#3933276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3933276 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
