[
https://issues.apache.org/jira/browse/OAK-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-7200.
--------------------------------
Resolution: Fixed
Fix Version/s: 1.10
1.9.0
Resolved mostly at [r1822372|https://svn.apache.org/r1822372] - technically,
for a new/failing index despite async lane working, we should probably plan for
"sync" indexes. But, that case is too general/complicated-to-fix to be in
purview of this issue.
> Sync propery indexes don't get planned if /:async exists but indexing lane
> hasn't completed its first cycle
> -----------------------------------------------------------------------------------------------------------
>
> Key: OAK-7200
> URL: https://issues.apache.org/jira/browse/OAK-7200
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Major
> Fix For: 1.9.0, 1.10
>
> Attachments: OAK-7200.patch
>
>
> In some cases (one example at \[0]), the repository might have a visible
> {{/:async}} node but first indexing lane isn't completed yet. In this
> situation sync property definitions (which are part of unfinished first
> indexing cycle) don't participate in query planning.
> The issue is basically that {{IndexNodeManager#open}} just looks at existence
> of {{/:async}} node to see if first indexing cycle is finished. It should
> also verify that the corresponding indexing lane is also done at least once
> (e.g. {{/:async/@<lane>}} exists.
> \[0]:
> Startup a 2 node (N1 and N2) cluster with async indexing being run on say N1
> - consider async lane = {{some-lane-async}}
> * N1 takes lease for {{some-lane-async}} and hence creates {{/:async}}
> * N1 starts first indexing cycle for {{some-lane-async}}
> * required background udpates happen such that N2 sees these updates from N1
> * N2 tries to a address a query which "should" get answered by a sync prop
> defn that is to be indexed in {{some-lane-async}}
> * N2 see {{/:async}} and assumes that first cycle is finished for the lane
> and hence expects some indexed data for the index definition (which isn't
> there yet)
> * Thus N2 doesn't utilize the index definition while planning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
