[
https://issues.apache.org/jira/browse/OAK-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866061#comment-15866061
]
Vikas Saurabh commented on OAK-5649:
------------------------------------
+1, patch looks good to me. Btw, would you know of an example case where it
happened? What I'm wondering is: should we track if say there are 10
consecutive exceptions and then do something about it (do something probably
equal (1) stop nrt, (2) show it somewhere in jmx). Otoh, if this is likely a
transient (I hope sitll unexpected though), then ignore whatever I said (I'm
non transient failure would flood the logs?!)
> Error in RefreshPolicy can lead to IndexNode lock leak
> ------------------------------------------------------
>
> Key: OAK-5649
> URL: https://issues.apache.org/jira/browse/OAK-5649
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Affects Versions: 1.6.0
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.7.0, 1.8, 1.6.1
>
> Attachments: OAK-5649-v1.patch
>
>
> {{IndexNode}} uses a ReadWriteLock which is "acquired" and "released".
> {code}
> boolean acquire() {
> lock.readLock().lock();
> if (closed) {
> lock.readLock().unlock();
> return false;
> } else {
> refreshPolicy.refreshOnReadIfRequired(refreshCallback);
> return true;
> }
> }
> {code}
> Its possible that any exception thrown in
> {{RefreshPolicy#refreshOnReadIfRequired}} can lead to lock being acquired but
> not released causing the lock to be lost and any further attempt to close
> such IndexNode instance would block indefinitely.
> As a fix the {{acquire}} call should account for any potential exception
> thrown in any call made from within that method call
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
