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

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
            Priority: Minor


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.

     [ https://issues.apache.org/jira/browse/SOLR-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

gabriele renzi updated SOLR-1538:
---------------------------------

    Attachment: SOLR-1538.patch

simply switch order of ollections allocation and lock aquisition, all tests still pass and it makes the locked zone smaller

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