WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId - Unknown parent node with id ...ERROR ... failed to read bundle: ...
Ces problèmes peuvent avoir plusieurs causes. Causes possibles (selon la version CRX) :
La cause la plus fréquente est la modification simultanée utilisant la même session. Dans ce cas, le fichier CRX error.log contient probablement au moins une exception ConcurrentModificationException.
Ces symptômes indiquent des incohérences au niveau de l'index, et peut-être aussi au niveau de l'espace de travail.
Généralement, l’impact d’une incohérence est faible. Un problème est survenu car le fichier journal est rempli de messages d'erreur dus à une incohérence.
Les incohérences de l’index de recherche peuvent se produire en raison des éléments suivants :
Il existe deux façons de corriger les incohérences de l’index de recherche :
Vous pouvez exécuter une vérification de cohérence d'index au démarrage. Dans le workspace.xml, ajoutez deux paramètres dans l'élément <SearchIndex class="..."> :
<param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/>
Un troisième paramètre détermine si les erreurs doivent être réparées ou si elles doivent être consignées uniquement :
<param name="autoRepair" value="false"/> <!-- default is true -->
<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/> <param name="autoRepair" value="true"/> </SearchIndex>
La regénération de l'index de recherche résoudra toutes ses incohérences. Toutefois, elle prendra beaucoup plus de temps que les processus de vérification et de correction de l’index. Pour cette raison, soyez extrêmement prudent avant de planifier la regénération de l'index de recherche. En cas de manque de temps, effectuez plutôt une vérification et une réparation.
Planification de la regénération de l'index
Étant donné que le temps nécessaire à la régénération de l’index dépend de nombreux et différents facteurs (tels que le nombre total de nœuds, de tailles et de types de fichiers ressources), vous devez tout d’abord tester l'opération dans un environnement de non-production. Utilisez le test de non-production pour calculer la durée d’une fenêtre d'interruption dont vous aurez besoin en production. Les petits référentiels dans la taille de 2 à 10 Go peuvent prendre de 30 min à 6 h, les plus grands de 6 h à 2 jours.
Comment regénérer l'index.
Pour générer à nouveau l’index de recherche, procédez comme suit :
En l'absence de résultat et affichage ou impression des erreurs qui ne peuvent être réparées, il se peut que les données de l'espace de travail soient incohérentes.
Les gestionnaires de rémanence peuvent vérifier la cohérence du référentiel et résoudre les problèmes au démarrage. Pour activer la vérification de cohérence et résoudre automatiquement les problèmes, ajoutez les paramètres suivants dans les fichiers repository.xml et workspace.xml, dans chaque élément <PersistenceManager class="...">, puis redémarrez CRX.
Dans une installation CQ5.2.x par défaut, ces fichiers sont stockés sous crx-quickstart/repository/workspaces/*/workspace.xml et crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.
Dans CQ5.3, le fichier repository.xml est stocké sous crx-quickstart/repository/repository.xml.
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
Une vérification ou une correction (index ou gestionnaire de rémanence Persistence Manager) sera effectuée au prochain démarrage. Une fois la vérification de cohérence terminée, désactivez les paramètres appropriés, pour éviter que la vérification de cohérence ne s’exécute à chaque démarrage de CRX.
Si seul le contrôle de cohérence est activé, un fichier inconsistentBundleIds.txt est créé dans le répertoire de l'espace de travail.
Si seul le paramètre compatibilityFix est activé, le fichier inconsistentBundleIds.txt est lu et ces nœuds sont corrigés. Le fichier est ensuite supprimé si tout peut être réparé.
Lors de l'exécution d'une correction de cohérence dans un environnement en cluster, exécutez-la uniquement sur un nœud de clusters. Ne démarrez pas d'autres nœuds de clusters tant que le correctif de cohérence est en cours d'exécution. À la fin de son exécution, les autres nœuds de clusters peuvent être démarrés.
La vérification de cohérence analyse tous les nœuds et s'avère donc assez lente. Pour réduire le temps de maintenance, envisagez d'exécuter la vérification de cohérence sur une copie du référentiel, puis corrigez simplement les nœuds endommagés. Procédez comme suit pour effectuer cette opération :
Pour limiter la vérification de la cohérence et corriger une liste de nœuds, ajoutez les UUID de ces nœuds dans l'option de configuration « consistencyCheckUUIDs » :
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyCheckUUIDs" value="ea9cb12f-8a8f-4820-88b1-6d1c496a07cd,741c905c-cfb0-422f-acd4-e0a9cbde46c6" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
À partir de CRX 2.2, vous pouvez ajouter ce paramètre jvm au démarrage de CRX / CQ5 pour éviter les corruptions :
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true
Si vous utilisez le serveur CQSE quickstart, vous pouvez ajouter le paramètre à la variable JVM_OPTS, par exemple :
crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
ou crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
L'utilisation de la propriété système validateheirarchy entraîne une légère dégradation des performances des opérations de sauvegarde de session dans le référentiel. Lors de la planification de l'utilisation de cette fonctionnalité, il est recommandé de charger préalablement les tests pour voir leur impact. Cela s'applique surtout si vous avez une application en écriture lourde.
Assurez-vous de désactiver l'optimisation tar lorsque la vérification de cohérence est planifiée afin d'éviter l'exécution de l'optimisation du tar et du contrôle de cohérence en parallèle.
1.X, 2.X.
Accéder à votre compte