[
https://issues.apache.org/jira/browse/SOLR-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-1538.
----------------------------
Resolution: Fixed
Fix Version/s: 1.5
Committed revision 898119.
> 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
> Fix For: 1.5
>
> 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.
