[
https://issues.apache.org/jira/browse/OAK-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731537#comment-15731537
]
Marcel Reutegger commented on OAK-5238:
---------------------------------------
bq. One possible approach can be to use a in memory builder in OakDirectory and
merge that back to main builder upon close. This would ensure that concurrent
access is avoided.
Yes, this should work, but I would merge it back earlier and not on close. On
re-index the directory may see a lot of changes and I think it's better to not
buffer them all in memory, even if binaries go into the blob store. The node
states still contain binary references of significant size. Maybe the
IndexCopier could create the blob asynchronously and then update the node
builder while holding a lock? I'll work on a patch.
> IndexCopier causes concurrent update on NodeBuilder
> ---------------------------------------------------
>
> Key: OAK-5238
> URL: https://issues.apache.org/jira/browse/OAK-5238
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Affects Versions: 1.2.3, 1.0.15, 1.4.0
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Labels: candidate_oak_1_4
> Fix For: 1.6
>
> Attachments: OAK-5238.patch
>
>
> OAK-2247 introduced the copy-on-write feature for lucene index in Oak. This
> feature may result in a NodeBuilder updated by multiple threads concurrently.
> New index files are first stored on the local filesystem and then copied
> asynchronously into the repository. At the same time the async index update
> thread manipulates the node builders as well.
> With MongoMK this results in unexpected conflicts and failed async index
> updates.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
