[
https://issues.apache.org/jira/browse/OAK-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316394#comment-15316394
]
Vikas Saurabh commented on OAK-4412:
------------------------------------
Just to clarify - which problem are we trying to solve:
# sometimes, due do delay in async indexing and background read, subsequent
request from the same user get missing (yet un-indexed/un-bkRead) result?
# some code patterns which currently _expect_ synchronous nature of property
index (do change -> save -> query -> expect earlier save to show up) won't cope
well with async nature?
I understand the former problem statement has value and worth solving. But, my
reading of this issue felt like we are trying to address the latter (code
expectation requires sync nature BUT prop indices are currently expensive).
I think, due to different expectations (wrt to timings - diff between 2 user
requests v/s diff between 2 actions in same call stack) we might want to
discuss the 2 problems separately. It'd great if same solution solves both
cases - but I think we shouldn't force same solution for both cases.
> Lucene-memory property index
> ----------------------------
>
> Key: OAK-4412
> URL: https://issues.apache.org/jira/browse/OAK-4412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Reporter: Tomek Rękawek
> Assignee: Tomek Rękawek
> Fix For: 1.6
>
> Attachments: OAK-4412.patch
>
>
> When running Oak in a cluster, each write operation is expensive. After
> performing some stress-tests with a geo-distributed Mongo cluster, we've
> found out that updating property indexes is a large part of the overall
> traffic.
> The asynchronous index would be an answer here (as the index update won't be
> made in the client request thread), but the AEM requires the updates to be
> visible immediately in order to work properly.
> The idea here is to enhance the existing asynchronous Lucene index with a
> synchronous, locally-stored counterpart that will persist only the data since
> the last Lucene background reindexing job.
> The new index can be stored in memory or (if necessary) in MMAPed local
> files. Once the "main" Lucene index is being updated, the local index will be
> purged.
> Queries will use an union of results from the {{lucene}} and
> {{lucene-memory}} indexes.
> The {{lucene-memory}} index, as a local stored entity, will be updated using
> an observer, so it'll get both local and remote changes.
> The original idea has been suggested by [~chetanm] in the discussion for the
> OAK-4233.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
