[
https://issues.apache.org/jira/browse/OAK-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608122#comment-14608122
]
Chetan Mehrotra commented on OAK-3053:
--------------------------------------
Added a testcase reproducing the issue with http://svn.apache.org/r1688421
Issue here is that in current indexing design the editors would not be invoked
if some exception happen during processing of commit. So if any editor like
{{LuceneIndexEditor}} has opened any non NodeStore based resource then it would
not get a chance to perform any cleanup. With CopyOnWrite mode enabled the
{{LuceneIndexEditor}} would hold a write lock which would not be released. This
would prevent any further indexing to happen as any call to open writer would
fail with {{LockObtainFailedException}}
> Locking issues seen with CopyOnWrite mode enabled
> -------------------------------------------------
>
> Key: OAK-3053
> URL: https://issues.apache.org/jira/browse/OAK-3053
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.2.3, 1.3.2, 1.0.17
>
>
> When CopyOnWrite mode is enabled and incremental mode is enabled i.e.
> {{indexPath}} property set then failure in any indexing cycle would prevent
> further indexing from progressing. For e.g. if any indexing cycle fails then
> subsequent indexing cycle would fail with Lucene locking related exception
> {noformat}
> Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain
> timed out:
> NativeFSLock@/tmp/junit8067118705344013640/2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae/1/write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:89)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:707)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.getWriter(LuceneIndexEditorContext.java:169)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.addOrUpdate(LuceneIndexEditor.java:293)
> ... 37 more
> {noformat}
> Any further indexing would continue to fail with this exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
