jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Parvulescu <alex.parvule...@gmail.com>
Subject Re: Question: In Repository Index file.
Date Fri, 06 Dec 2013 10:44:36 GMT

On Fri, Dec 6, 2013 at 11:06 AM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> Hi,
> On Fri, Dec 6, 2013 at 1:25 AM, Ian Boston <ieb@tfd.co.uk> wrote:
> > In Oak when a index is stored in the repository, how is it updated
> > when the repository is MongoDB backed and there are multiple JVM
> > processes connected to the MongoDB ?
> That depends on the index and MK implementations. For example the
> PropertyIndex uses an index structure that can be updated concurrently
> when the updates affect different areas of the content repository.
> When using the MongoMK backend concurrent updates to the same nodes
> will automatically be synchronized, and with the SegmentMK (which also
> can be used with MongoDB) all commits against the same journal are
> synchronized. In both cases concurrent updates will automatically get
> resolved.
> > Also if using SolrCloud as a search index, is it possible to fallback
> > to an internal repository stored index if the the SolrCloud index
> > becomes unavailable ?
> Yes. The query engine will automatically pick the best available index
> for each query execution. If a particular index is not available, then
> the second-best match for those queries that would have used it would
> automatically get picked.

There is one minor nitpick with this statement.

So far we've assumed that the solr index will be used for full-text queries
only. the only fallback you could use if the solr index becomes unavailable
is the lucene one, but as far as I know we've said that you would usually
use one _or_ the other.
Areas of concern are: the full-text indexing settings may differ, and the
cost output may need to be tricked into treating the local lucene index as
a fallback and not a competing full-text index.
But this is definitely doable.

> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message