L’analyse de données d’entrée volumineuses, rompues ou malveillantes provoque une utilisation excessive de la mémoire ou du processeur lors de l’indexation.

Dans les pire cas, la JVM se bloque.

Utilisez des compilateurs Tika dans des processus JVM distincts.

Pour mieux éviter ce type de situation et améliorer la gestion de la consommation de ressources par Tika, exécutez les analyseurs Tika dans des processus JVM distincts. Pour la mise en place, voir https://issues.apache.org/jira/browse/TIKA-416

Cette fonction permet l’indexation de texte intégral des documents binaires dans des processus JVM distincts. De cette manière, les problèmes provoqués par l’analyse de documents volumineux ou mal formés n’affectent pas le processus CRX ou CQ principal. Cette fonction augmente la fiabilité globale et la stabilité du système, tandis que les problèmes d’indexation sont mieux isolés.

La fonction lance automatiquement un pool de processus d’arrière-plan dédiés à l’extraction de texte intégral.

Démarrez les processus en cours à l'aide de la commande Java spécifié comme le paramètre «forkJavaCommand» du <SearchIndex/> dans la section workspace appropriée ou dans les fichiers de configuration du référentiel (généralement crx-quickstart/repository/workspaces/crx.default/workspace.xml).

Définissez cette valeur, par exemple, à «java -Xmx512m» pour activer cette fonction.

Conseil supplémentaire

Les processus d’extraction de texte en fourchette ne peuvent pas directement altérer le processus parent. Cependant, elles consomment beaucoup de temps CPU, surtout lors du traitement de documents PDF volumineux. Pour éviter ou contrôler l’effet sur les performances globales du système, activez l’option forkJavaCommand sur « nice » ou une autre commande spécifique à la plate-forme pour réduire la priorité d’exécution des processus d’extraction en fourchette. Les valeurs recommandées pour Linux et Windows sont les suivantes :

  Linux: "nice java -Xmx512m"
Windows: "cmd /c start /low /wait /b java -Xmx512m"

Windows :

        <SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
            <param name="path" value="${wsp.home}/index"/>
            <param name="resultFetchSize" value="100"/>
            <param name="cacheSize" value="100000" />
            <param name="forkJavaCommand" value="cmd /c start /low /wait /b java -Xmx512m"/>
        </SearchIndex>

Linux/Unix :

        <SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
<param name="path" value="${wsp.home}/index"/>
<param name="resultFetchSize" value="100"/>
<param name="cacheSize" value="100000" />
<param name="forkJavaCommand" value="nice java -Xmx512m"/>
</SearchIndex>

S’applique à

CRX 2.2, CRX 2.1 avec pack de correctifs >= 2.1.0.9 installé

Remarque :

Sous Linux, les commandes nice et java fonctionnent uniquement si elles sont accessibles dans la variable Path de la session shell de l'utilisateur CQ.

Dans Windows, les mêmes s'appliquent à la commande java, la variable PATH doit inclure le dossier corbeille correct de la version Java.

Cliquez ici pour plus de détails sur la définition de la variable «path» dans Java.

Informations supplémentaires

Par défaut, les analyseurs Tika qui prennent en charge cet extrait, s’exécutent dans le même processus Java que CQ, ce qui peut entraîner les symptômes décrits lorsqu’il rencontre des cas d’utilisation spécifiques.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne