[ https://issues.apache.org/jira/browse/SOLR-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man reassigned SOLR-1538: ------------------------------ Assignee: Hoss Man I'm not a threading/locking expert, but this seems straight forward enough. All the docs i've seen definitely say that a "try" block (with "unlock" in the finally) should be the very next line after any lock() call. > Solr possible deadlock source (FindBugs report) > ----------------------------------------------- > > Key: SOLR-1538 > URL: https://issues.apache.org/jira/browse/SOLR-1538 > Project: Solr > Issue Type: Bug > Affects Versions: 1.4 > Environment: platform independent > Reporter: gabriele renzi > Assignee: Hoss Man > Priority: Minor > Attachments: SOLR-1538.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > The code to get the latest accessed items in ConcurrentLRUCache looks like > {code:title=ConcurrentLRUCache.java|} > public Map<K, V> getOldestAccessedItems(int n) { > markAndSweepLock.lock(); > Map<K, V> result = new LinkedHashMap<K, V>(); > TreeSet<CacheEntry> tree = new TreeSet<CacheEntry>(); > try { > ... > } finally { > markAndSweepLock.unlock(); > } > {code} > (this method is apparently unused though) and in > {code} > public Map<K,V> getLatestAccessedItems(int n) { > // we need to grab the lock since we are changing lastAccessedCopy > markAndSweepLock.lock(); > Map<K,V> result = new LinkedHashMap<K,V>(); > TreeSet<CacheEntry> tree = new TreeSet<CacheEntry>(); > try { > ... > {code} > The impression is that if an OOM situation occurs on the allocation of the > local LinkedHashMap and TreeSet the lock would not be unlocked anymore. > The quick fix would be to move the lock() call after the allocations, and > this does not seem to imply any problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.