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

Chetan Mehrotra commented on OAK-5238:
--------------------------------------

May be we can split this in 2 parts
[~mreutegg] Patch looks fine. Few minor comments

* Changes around refactoring done for {{BlobFactory}}
* Actual fix done via OakBufferedDirectory

*BufferedOakDirectory*

* Move it to {{org.apache.jackrabbit.oak.plugins.index.lucene.directory}} 
package. So far avoid moving OakDirectory to that to minimize impact on 
backport. But new stuff we can add to the new package
* Indicated that file is already deleted in exception message. Same for 
openInput flow. This would help in distinguishing FNFE from base dir or 
buffered dir ... incase we need to analyze some issue 
{code}
     @Override
    public long fileLength(String name) throws IOException {
        if (bufferedForDelete.contains(name)) {
            throw new FileNotFoundException(name);
        }
{code}
* Include the index path in log messages
{noformat}
- LOG.debug("createOutput({})", name);
+ LOG.debug("[{}]createOutput({})", definition.getIndexPath(), name);
{noformat}
* Add a debug log in {{fileDeleted}} when builder is refereshed. Would be good 
to see if this part is  reached
* A testcase around builder refresh done in {{fileDeleted}} would be good

> 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-1.patch, 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)

Reply via email to