[jira] Assigned: (SOLR-1538) Solr possible deadlock source (FindBugs report)

["Hoss Man (JIRA)" <ji...@apache.org>]

     [ 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.