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) :
- Modification simultanée utilisant la même session : https://issues.apache.org/jira/browse/JCR-2456
- Le nœud déplacé disparaît après l'actualisation :https://issues.apache.org/jira/browse/JCR-1883
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.
Types d’incohérences
- Orphelin
- Message d'erreur : NodeState CHILD_UUID references inexistent parent quid PARENT_UUID.
- Message de vérification de cohérence : ConsistencyCheck: Not repairable: Node
CHILD_UUID has unknown parent:
PARENT_UUID (ConsistencyCheck.java, line 116) - Solution actuelle : Utilisez la console CRX Console (voir article)
- Parent référençant un enfant inexistant
- Message d’erreur : NodeState PARENT_UUID references inexistent child {}CHILD_NAME with id CHILD_UUID
- Solution actuelle : une vérification de la cohérence devrait régler ce problème
- Enfant référençant un parent invalide
- Message d’erreur : ChildNode has invalid parent quid: INVALID_PARENT_UUID (instead of VALID_PARENT_UUID)
- Solution actuelle : utilisez la console CRX (voir article)
- Parent ne référençant pas un enfant existant
- Message d'erreur : javax.jcr.ItemNotFoundException: failed to build path of CHILD_UUID: PARENT_UUID has no child entry for CHILD_UUID
- Solution actuelle : utilisez la console CRX (voir article)
- Un nœud détecté.
- Message d'erreur : javax.jcr.ItemExistsException: <node_path> at org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:766)
- Solution actuelle : une vérification de la cohérence devrait régler ce problème
- Incident d'index de recherche
- Message d'erreur : WARN NodeIteratorImpl: Exception retrieving Node with UUID: 003171fe-e2e8-457b-a3af-f74eed12c1b9: javax.jcr.ItemNotFoundException: 003171fe-e2e8-457b-a3af-f74eed12c1b9
- Solution actuelle : recréer l'index de recherche ou exécuter la vérification de la cohérence de l'index de recherche et corriger les erreurs
- Incident survenu au cours de la recherche
- Message d'erreur : "Caused by: javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496" où "org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getNode" peut s'afficher dans la trace d'appels.
- Solution actuelle : activez la case adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix"> Vérification de la cohérence et correction de l'index.
- Incompatibilité liée à la version
- La pile des messages d'erreur indique qu'elle est liée au code org.apache.jackrabbit.core.version.InternalXAVersionManager.
- Solution actuelle : vérifiez cet article.
- Fichier introuvable.
- Message d'erreur : ERROR TarPersistenceManager: Failed to read bundle: [quid]: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
java.io.IOException: File not found: nnnnn - Solution actuelle : vérifiez si vous pouvez trouver ce fichier dans une sauvegarde (data_nnnnn.tar) ou supprimer le fichier index_*.tar pour le reconstruire au redémarrage.
- Message d'erreur : ERROR TarPersistenceManager: Failed to read bundle: [quid]: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
Réparation de votre index de recherche
Les incohérences de l’index de recherche peuvent se produire en raison des éléments suivants :
- Arrêt inapproprié du processus Java pendant une opération d'écriture. Un kill -9 sous Linux ou Unix ou un processus kill (tuer) du Gestionnaire des tâches sous Windows.
- Quelques bugs plus anciens dans CRX, qui ont été corrigés dans les dernières versions des correctifs CQ et CRX (pour CRX 2.2, 2.3 et 2.4). Pour éviter ces problèmes, il convient de vous tenir au courant des derniers correctifs CRX. Si vous pensez que vous n'utilisez pas le dernier correctif, soumettez un ticket au support Adobe pour demander le dernier correctif.
Il existe deux façons de corriger les incohérences de l’index de recherche :
- Exécutez une vérification de la cohérence de l'index de recherche et corrigez-la si nécessaire.
- Recréez l'index de recherche.
Vérifiez la cohérence de l'index de recherche et corrigez-la si nécessaire.
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>
Regénération de l'index de recherche
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 :
- Arrêter CRX (ou CQ)
- Sauvegardez et supprimez les répertoires suivants dans votre référentiel : crx-quickstart/repository/workspaces/crx.default/index/ and crx-quickstart/repository/repository/index/
- Lancez CRX (ou CQ), pour initier la reconstruction. Dans CRX 2.2, surveillez les logs/crx/error.log et dans CRX 2.3 monitor logs/error.log pour voir la progression. Vous pouvez dire que l'indexation est effectuée lorsque l'instance CRX est accessible.
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é.
Correction des incohérences dans un cluster
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.
Correction rapide des incohérences
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 :
- Copiez le référentiel à l'aide de la fonctionnalité de sauvegarde en ligne.
- Exécutez la vérification de cohérence et procédez aux corrections appropriées (comme décrit ci-dessus) sur la copie du référentiel, éventuellement sur une autre machine.
- Dans le fichier journal CRX, recherchez les UUID des noeuds corrompus.
- Dans le référentiel d'origine, exécutez la vérification de cohérence et corrigez uniquement les nœuds corrompus.
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
Remarque :
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.
Remarque :
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.
Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.