[exo-jcr-commits] exo-jcr SVN: r5540 - jcr/branches/1.14-RSYNC/exo.jcr.docs/exo.jcr.docs.developer/en/src/main/docbook/en-US/modules/jcr.

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 @@ &lt;/properties&gt; &lt;/query-handler&gt; </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">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter" /&gt;</programlisting> + <programlisting language="xml">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter" /&gt;</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">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter" /&gt; + <programlisting language="xml">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.DocNumberRecoveryFilter" /&gt; &lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.SystemPropertyRecoveryFilter" /&gt; </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">&lt;property name="index-recovery-mode" value="from-coordinator" /&gt; + <programlisting language="xml">&lt;property name="index-recovery-mode" value="from-coordinator" /&gt; </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">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter" /&gt; + <programlisting language="xml">&lt;property name="index-recovery-filter" value="org.exoplatform.services.jcr.impl.core.query.lucene.ConfigurationPropertyRecoveryFilter" /&gt; &lt;property name="index-recovery-filter-forcereindexing" value="true" /&gt; </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>