lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-1538) Solr possible deadlock source (FindBugs report)
Date Thu, 27 May 2010 23:09:39 GMT

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

Hoss Man updated SOLR-1538:
---------------------------

    Fix Version/s: 3.1
                   4.0


Correcting Fix Version based on CHANGES.txt, see this thread for more details...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E


> 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, 3.1, 4.0
>
>         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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message