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 2019/08/02 05:29:00 UTC

[jira] [Commented] (OAK-8513) Concurrent index access via CopyOnRead directory can lead to reading directly off of remote

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

Vikas Saurabh commented on OAK-8513:
------------------------------------

[~tmueller], while I've committed the change, it'd great if you can have a look.

> Concurrent index access via CopyOnRead directory can lead to reading directly off of remote
> -------------------------------------------------------------------------------------------
>
>                 Key: OAK-8513
>                 URL: https://issues.apache.org/jira/browse/OAK-8513
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: lucene
>            Reporter: Vikas Saurabh
>            Assignee: Vikas Saurabh
>            Priority: Major
>             Fix For: 1.18.0
>
>
> Even with prefetch enabled having 2 CopyOnRead directories pointing to same index can lead to one of the instance reading index files directly off of remote index.
> The reason this happens is because {{COR#copyFilesToLocal}} explicitly chooses to work with remote if index copier reports that a copy is in progress.
> This wasn't a problem earlier when COR was only used via IndexTracker so concurrent COR instances weren't expected (COR's avoid local for conc copy was probably worried about non-prefetch case).
> But with OAK-8097, {{DefaultDirectoryFactory}} also uses COR to bring the files. Which means that if there's a query against an index which is getting updated as well then either of COR instance could read directly from remote.
> The condition should only be relevant during early app start up but since this can happen in default configuration, we should attempt to fix this.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)