[
https://issues.apache.org/jira/browse/OAK-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15438834#comment-15438834
]
Chetan Mehrotra edited comment on OAK-4412 at 9/5/16 3:32 PM:
--------------------------------------------------------------
Work is being in fork on github at
* Branch - https://github.com/chetanmeh/jackrabbit-oak/tree/OAK-4412
* Compare -
https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-4412
Base level feature working. Pending
# -OSGi integration- - Done in branch
# -Statistics Collection- - Done in branch
# Listening to external changes - Optional configurable feature
# -Synchronous indexing support- - Next level enhancement which ensures that
changes get pushed to index and reader get refreshed as part of commit itself.
Done in branch
# -Benchmark to compare performance on various setups wrt property indexes-
Done in branch. Results to be published
was (Author: chetanm):
Work is being in fork on github at
* Branch - https://github.com/chetanmeh/jackrabbit-oak/tree/OAK-4412
* Compare -
https://github.com/chetanmeh/jackrabbit-oak/compare/trunk...chetanmeh:OAK-4412
Base level feature working. Pending
# -OSGi integration- - Done in branch
# -Statistics Collection- - Done in branch
# Listening to external changes - Optional configurable feature
# Synchronous indexing support - Next level enhancement which ensures that
changes get pushed to index and reader get refreshed as part of commit itself
# Benchmark to compare performance on various setups wrt property indexes
> Lucene hybrid index
> -------------------
>
> Key: OAK-4412
> URL: https://issues.apache.org/jira/browse/OAK-4412
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: lucene
> Reporter: Tomek Rękawek
> Assignee: Chetan Mehrotra
> 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)
