You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "gabriele renzi (JIRA)" <ji...@apache.org> on 2009/11/01 12:52:59 UTC
[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.
[jira] Resolved: (SOLR-1538) Solr possible deadlock source
(FindBugs report)
Posted by "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 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.
[jira] Assigned: (SOLR-1538) Solr possible deadlock source
(FindBugs report)
Posted by "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.
[jira] Updated: (SOLR-1538) Solr possible deadlock source (FindBugs
report)
Posted by "gabriele renzi (JIRA)" <ji...@apache.org>.
[ 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.