You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Vikas Saurabh (JIRA)" <ji...@apache.org> on 2017/02/14 16:26:41 UTC

[jira] [Comment Edited] (OAK-5649) Error in RefreshPolicy can lead to IndexNode lock leak

    [ https://issues.apache.org/jira/browse/OAK-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866061#comment-15866061 ] 

Vikas Saurabh edited comment on OAK-5649 at 2/14/17 4:26 PM:
-------------------------------------------------------------

+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?!)

PS: Of course, the latter part is about improving the behavior - not for 1.6.1.


was (Author: catholicon):
+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)