"manik.surtani(a)jboss.com" wrote : 1) Should the eviction thread always use a lock acquisition timeout of 0, simply because if anyone else has a lock on the node being evicted then it should not be evicted? Since this is algorithm-specific, the BaseEvictionPolicy's evict() method should return an appropriate value if the eviction failed because of a timeout (rather than throw an exception, as this may be quite common with a timeout of 0) I don't think it is necessarily true that if a node has a read/write lock, it should not be evicted. Take for example the eivction policy of FIFO or policy with a node max age. Both will evict the corresponding node even when it just has been accessed. Unfortunately, I still don't see how eviction timeout will cause deadlock or slow system down though? This can happen if the event queue has been filled up. But Manik has made the queue size configurable now. So theorectically, we should not run into this problem anymore. Therefore, making the timeout of 0 may not be necessarily anymore. "manik.surtani(a)jboss.com" wrote : 2) BaseEvictionAlgorithm.evictCacheNode(), which calls BaseEvictionPolicy.evict(), would have to decide on whether a failure to evict because of a timeout should result in the eviction call being put back on the queue. In the case of an LRU type policy, this probably should *not* happen since the fact that the node is locked, it should be treated as a nodeVisited event and this eviction call should be removed from the eviction queue. If we fail to evict the node, it will be put into a special recycle queue to be process again within the next cycle. When the nodeVisited event comes in, it is supposed to remove node event from both queues. If it is not, then it is a bug. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980657#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...