well, obviously member 10.0.20.90:40519 held a lock, so you need to investigate what heppens on 10.0.20.90:40519. If 10.0.20.90:40519 is the coordinator, then it will read-lock its tree briefly to return the state to a new member. Otherwise, read-locks are generally acquired for get() methods, write-locks for put() and remove() methods. The eviction policy also tries to acquire a read-lock when it need to evict an element from memory. TreeCache.printLockInfo() dumps all locks held by a cache.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3892058#3892058 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3892058 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
