jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-5649) Error in RefreshPolicy can lead to IndexNode lock leak
Date Tue, 14 Feb 2017 16:26:41 GMT

    [ 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)

Mime
View raw message