ben-manes commented on issue #1975: URL: https://github.com/apache/accumulo/issues/1975#issuecomment-807846622
This might be slightly different, but similar. https://github.com/apache/accumulo/blob/1dc72fce2c781dee597c8c11876a3bc6c321c199/core/src/main/java/org/apache/accumulo/core/file/blockfile/cache/tinylfu/TinyLfuBlockCache.java#L202-L209 This calls `policy.getMaximum()` which currently reads under the eviction policy's lock as it is a non-volatile field. That called under the a `ConcurrentHashMap#compute` method, which takes a lock on the hashbin. If another thread is evicting, it would hold the policy lock and a hash collision might require the same hashbin lock for the entry's removal. This would cause the deadlock you are seeing. One solution is to store the maxSize as a local variable, since it is never changed. I suppose the policy's accessor was used for convenience. Another option is if Caffeine made this field a volatile so it could be read lock-free. That wasn't done since its otherwise used under the lock (being set, eviction) and policy methods are not expected to be called frequently. There are other methods on policy that need the lock, so we could only solves a few simple cases. In this case, I think stashing the maximum size as a final field would be simplest and not require a dependency to be released. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
