Author: nzamosenchuk
Date: 2012-01-30 03:34:51 -0500 (Mon, 30 Jan 2012)
New Revision: 5540
Modified:
jcr/branches/1.14-RSYNC/exo.jcr.docs/exo.jcr.docs.developer/en/src/main/docbook/en-US/modules/jcr/query-handler-config.xml
Log:
EXOJCR-1711 : updating documentation
Modified:
jcr/branches/1.14-RSYNC/exo.jcr.docs/exo.jcr.docs.developer/en/src/main/docbook/en-US/modules/jcr/query-handler-config.xml
===================================================================
---
jcr/branches/1.14-RSYNC/exo.jcr.docs/exo.jcr.docs.developer/en/src/main/docbook/en-US/modules/jcr/query-handler-config.xml 2012-01-28
15:36:17 UTC (rev 5539)
+++
jcr/branches/1.14-RSYNC/exo.jcr.docs/exo.jcr.docs.developer/en/src/main/docbook/en-US/modules/jcr/query-handler-config.xml 2012-01-30
08:34:51 UTC (rev 5540)
@@ -412,81 +412,83 @@
</properties>
</query-handler>
</programlisting>
- </section>
- <section>
- <title>Local Index Recover Filters</title>
+ <section>
+ <title>Local Index Recover Filters</title>
- <para>Common usecase for all cluster-ready applications is a hot
- joining and leaving of processing units. Node that is joining cluster
- for the first time or node joining after some downtime, they all must
- be in a synchronized state. When having a deal with shared value
- storages, databases and indexes, cluster nodes are synchronized
- anytime. But it's an issue when local index strategy used. If new node
- joins cluster, having no index it is retrieved or recreated. Node can
- be restarted also and thus index not empty. By default existing index
- is thought to be actual, but can be outdated. JCR offers a mechanism
- called RecoveryFilters that will automatically retrieve index for the
- joining node on startup. This feature is a set of filters that can be
- defined via QueryHandler configuration:</para>
+ <para>Common usecase for all cluster-ready applications is a hot
+ joining and leaving of processing units. Node that is joining
+ cluster for the first time or node joining after some downtime, they
+ all must be in a synchronized state. When having a deal with shared
+ value storages, databases and indexes, cluster nodes are
+ synchronized anytime. But it's an issue when local index strategy
+ used. If new node joins cluster, having no index it is retrieved or
+ recreated. Node can be restarted also and thus index not empty. By
+ default existing index is thought to be actual, but can be outdated.
+ JCR offers a mechanism called RecoveryFilters that will
+ automatically retrieve index for the joining node on startup. This
+ feature is a set of filters that can be defined via QueryHandler
+ configuration:</para>
- <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter"
/></programlisting>
+ <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter"
/></programlisting>
- <para>Filter number is not limited so they can be combined:</para>
+ <para>Filter number is not limited so they can be combined:</para>
- <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter"
/>
+ <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter"
/>
<property name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.SystemPropertyRecoveryFilter"
/>
</programlisting>
- <para>If any one returns fires, the index is re-synchronized. This
- feature uses standard index recovery mode defined by previously
- described parameter (can be "from-indexing" (default) or
- "from-coordinator")</para>
+ <para>If any one returns fires, the index is re-synchronized. This
+ feature uses standard index recovery mode defined by previously
+ described parameter (can be "from-indexing" (default) or
+ "from-coordinator")</para>
- <programlisting language="xml"><property
name="index-recovery-mode" value="from-coordinator" />
+ <programlisting language="xml"><property
name="index-recovery-mode" value="from-coordinator" />
</programlisting>
- <para>There are couple implementations of filters:</para>
+ <para>There are couple implementations of filters:</para>
- <itemizedlist>
- <listitem>
-
<para>org.exoplatform.services.jcr.impl.core.query.lucene.DummyRecoveryFilter:
- always returns true, for cases when index must be force
- resynchronized (recovered) each time;</para>
- </listitem>
+ <itemizedlist>
+ <listitem>
+
<para>org.exoplatform.services.jcr.impl.core.query.lucene.DummyRecoveryFilter:
+ always returns true, for cases when index must be force
+ resynchronized (recovered) each time;</para>
+ </listitem>
- <listitem>
-
<para>org.exoplatform.services.jcr.impl.core.query.lucene.SystemPropertyRecoveryFilter
- : return value of system property
- "org.exoplatform.jcr.recoveryfilter.forcereindexing". So index
- recovery can be controlled from the top without changing
- documentation using system properties;</para>
- </listitem>
+ <listitem>
+
<para>org.exoplatform.services.jcr.impl.core.query.lucene.SystemPropertyRecoveryFilter
+ : return value of system property
+ "org.exoplatform.jcr.recoveryfilter.forcereindexing". So index
+ recovery can be controlled from the top without changing
+ documentation using system properties;</para>
+ </listitem>
- <listitem>
-
<para>org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter
- : return value of QueryHandler configuration property
- "index-recovery-filter-forcereindexing". So index recovery can be
- controlled from configuration separately for each workspace.
- I.e:</para>
+ <listitem>
+
<para>org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter
+ : return value of QueryHandler configuration property
+ "index-recovery-filter-forcereindexing". So index recovery can
+ be controlled from configuration separately for each workspace.
+ I.e:</para>
- <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter"
/>
+ <programlisting language="xml"><property
name="index-recovery-filter"
value="org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter"
/>
<property name="index-recovery-filter-forcereindexing"
value="true" />
</programlisting>
- </listitem>
+ </listitem>
- <listitem>
-
<para>org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter
- : checks number of documents in index on coordinator side and
- self-side. Return true if differs. Advantage of this filter
- comparing to other, it will skip reindexing for workspaces where
- index wasn't modified. I.e. there is 10 repositories with 3
- workspaces in each one. Only one is really heavily used in cluster
- : frontend/production. So using this filter will only reindex
- those workspaces that are really changed, without affecting other
- indexes thus greatly reducing startup time.</para>
- </listitem>
- </itemizedlist>
+ <listitem>
+
<para>org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter
+ : checks number of documents in index on coordinator side and
+ self-side. Return true if differs. Advantage of this filter
+ comparing to other, it will skip reindexing for workspaces where
+ index wasn't modified. I.e. there is 10 repositories with 3
+ workspaces in each one. Only one is really heavily used in
+ cluster : frontend/production. So using this filter will only
+ reindex those workspaces that are really changed, without
+ affecting other indexes thus greatly reducing startup
+ time.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
</section>
</section>
Show replies by date