WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId -
Unknown parent node with id ...ERROR ... failed to read bundle: ...
Diese Probleme können mehrere Ursachen haben. Mögliche Ursachen (abhängig von der CRX-Version) sind:
- Gleichzeitige Änderung in derselben Sitzung: https://issues.apache.org/jira/browse/JCR-2456.
- Der verschobene Knoten verschwindet nach der Aktualisierung: https://issues.apache.org/jira/browse/JCR-1883.
Die häufigste Ursache ist die gleichzeitige Änderung, während dieselbe Sitzung benutzt wird. In diesem Fall enthält die Datei CRX error.log höchstwahrscheinlich mindestens eine ConcurrentModificationException.
Diese Symptome deuten darauf hin, dass der Index (und möglicherweise auch der Arbeitsbereich) inkonsistent sein können.
Normalerweise ist die Auswirkung einer Inkonsistenz gering. Ein Problem besteht darin, dass die Logdatei aufgrund einer Inkonsistenz mit Fehlermeldungen gefüllt ist.
Arten von Inkonsistenzen.
- Isoliertes untergeordnetes Element.
- Fehlermeldung: NodeState CHILD_UUID verweist auf nicht vorhandene übergeordnete UUID PARENT_UUID.
- Konsistenzprüfungsnachricht: Konsistenzprüfung: Nicht reparierbar: Knoten
CHILD_UUID hat ein unbekanntes übergeordnetes Element:
PARENT_UUID (ConsistencyCheck.java, Zeile 116). - Aktuelle Lösung: Verwenden Sie die CRX-Konsole (siehe Artikel).
- Übergeordnetes Element verweist auf nicht vorhandenes untergeordnetes Element
- Fehlermeldung: NodeState PARENT_UUID verweist auf das nicht vorhandene untergeordnete Element {}CHILD_NAME mit der ID CHILD_UUID.
- Aktuelle Lösung: Konsistenzprüfung/Korrektur sollte solch ein Problem beheben.
- Untergeordnetes Element verweist auf ungültiges übergeordnetes Element.
- Fehlermeldung: ChildNode hat ungültiges übergeordnetes Quid: INVALID_PARENT_UUID (anstelle von VALID_PARENT_UUID).
- Aktuelle Lösung: Verwenden Sie die CRX-Konsole (siehe Artikel).
- Übergeordnetes Element verweist nicht auf vorhandenes untergeordnetes Element.
- Fehlermeldung: javax.jcr.ItemNotFoundException: Fehler beim Erstellen des Pfads von CHILD_UUID: PARENT_UUID hat keinen untergeordneten Eintrag für CHILD_UUID.
- Aktuelle Lösung: Verwenden Sie die CRX-Konsole (siehe Artikel).
- Knoten vorhanden.
- Fehlermeldung: javax.jcr.ItemExistsException: <node_path> at org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:766).
- Aktuelle Lösung: Konsistenzprüfung/Korrektur sollte solch ein Problem beheben.
- Suchindex-Inkonsistenz.
- Fehlermeldung: WARN NodeIteratorImpl: Ausnahme beim Abrufen von Knoten mit UUID: 003171fe-e2e8-457b-a3af-f74eed12c1b9: javax.jcr.ItemNotFoundException: 003171fe-e2e8-457b-a3af-f74eed12c1b9.
- Aktuelle Lösung: Suchindex neu erstellen oder eine Suchindex-Konsistenzprüfung und Korrektur durchführen.
- Inkonsistenz der Suche.
- Fehlermeldung: „Verursacht durch: javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496“, wobei „org.apache.jackrabbit.core.query.lucene.RowIteratorImpl $ RowImpl.getNode“ im Stacktrace zu sehen ist.
- Aktuelle Lösung: Überprüfen Sie die Konsistenz des adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix">-Suchindex und korrigieren Sie.
- Versionsbezogene Inkonsistenz.
- Der Fehlermeldungsstapel zeigt, dass ein Zusammenhang mit dem org.apache.jackrabbit.core.version.InternalXAVersionManager-Code besteht.
- Aktuelle Lösung: Sehen Sie in diesem Artikel nach.
- Datei nicht gefunden.
- Fehlermeldung: 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 - Aktuelle Lösung: Überprüfen Sie, ob Sie diese Datei in einer Sicherung finden (data_nnnnn.tar), oder entfernen Sie den index_*.tar, um ihn beim Neustart neu zu erstellen.
- Fehlermeldung: ERROR TarPersistenceManager: Failed to read bundle: [quid]: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
Reparieren Ihres Suchindex
.
Suchindexinkonsistenzen können aufgrund folgender Ursachen auftreten:
- Unsauberes Herunterfahren des Java-Prozesses während eines Schreibvorganges. Dies wäre ein Abbruch -9 in Linux oder Unix und ein Task-Manager-Prozess-Abbruch im Windows Betriebssystem.
- Einige ältere Fehler in CRX, welche mit den letzten CQ- und CRX-Hotfixes behoben wurden (für CRX2.2, 2.3 und 2.4). Um solche Probleme zu vermeiden, sollten Ihre CRX-Hotfixes auf dem neuesten Stand sein. Wenn Sie der Meinung sind, dass Sie nicht über das neueste Hotfix verfügen, senden Sie ein Supportticket an den Adobe-Support, um die neueste Korrektur anzufordern.
Es gibt zwei Möglichkeiten, um Suchindexinkonsistenzen zu korrigieren:
- Führen Sie eine Konsistenzprüfung und Korrektur für den Suchindex aus.
- Erstellen Sie Ihren Suchindex neu.
Konsistenzprüfung und Korrektur für den Suchindex.
Sie können beim Start eine Indexkonsistenzprüfung durchführen. Fügen Sie in der workspace.xml zwei Parameter im Element <SearchIndex class="..."> hinzu:
<param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/>
Ein dritter Parameter steuert, ob Fehler repariert werden sollen oder ob sie nur protokolliert werden sollen:
<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>
Erstellen Sie Ihren Suchindex neu.
Wenn Sie Ihren Suchindex neu erstellen, werden alle Suchindexinkonsistenzen korrigiert. Es dauert jedoch wesentlich länger als die Konsistenzprüfung und Korrektur des Suchindex. Aus diesem Grund sollten Sie bei der Planung einer Neuerstellung des Suchindexes besonders vorsichtig sein, und wenn Sie sich nicht viele Ausfallzeiten leisten können, sollten Sie in Erwägung ziehen, stattdessen eine Überprüfung und Korrektur durchzuführen.
Planung der Neuerstellung Ihres Indexes.
Da die erforderliche Zeit für die Neuerstellung Ihres Indexes von vielen verschiedenen Faktoren abhängt (zum Beispiel der Gesamtanzahl der Knoten, Größe der Asset-Dateien und Asset-Dateitypen), sollten Sie zuerst die Wiederherstellung in einer Nicht-Produktionsumgebung testen. Verwenden Sie den Nicht-Produktionstest, um zu berechnen, wie lange Sie ein Ausfallfenster in der Produktion benötigen werden. Kleine Repositorys mit einer Größe von 2 bis 10 GB können 30 Minuten bis 6 Stunden in Anspruch nehmen, größere 6 Stunden bis 2 Tage.
Wie Sie den Index neu erstellen.
Gehen Sie folgendermaßen vor, um Ihren Suchindex neu zu erstellen:
- CRX beenden (oder CQ).
- Sichern und löschen Sie die folgenden Verzeichnisse in Ihrem Repository: crx-quickstart/repository/workspaces/crx.default/index/ and crx-quickstart/repository/repository/index/.
- Starten Sie CRX (oder CQ), dies wird die Neuerstellung initiieren. Überwachen Sie logs/crx/error.log in CRX2.2 und überwachen Sie logs/error.log in CRX2.3, um den Fortschritt zu beobachten. Wenn auf die CRX-Instanz zugegriffen werden kann, wissen Sie, dass die Indizierung abgeschlossen ist.
Wenn das nicht hilft und Fehler gedruckt werden, welche nicht repariert werden können, sind die Arbeitsbereichsdaten wahrscheinlich inkonsistent.
Persistenz-Managers können die Repository-Konsistenz überprüfen und Probleme beim Start korrigieren. Um die Konsistenzprüfung zu aktivieren und Probleme automatisch zu korrigieren, fügen Sie die folgenden Parameter in der repository.xml und workspace.xml innerhalb jedes <PersistenceManager class="...">-Elements hinzu und starten Sie CRX erneut.
In einer Standardinstallation von CQ5.2.x finden Sie diese Dateien unter crx-quickstart/repository/workspaces/*/workspace.xml und crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.
In CQ5.3 kann die repository.xml stattdessen unter crx-quickstart/repository/repository.xml gefunden werden.
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
<param name="consistencyCheck" value="true" />
<param name="consistencyFix" value="true" />
</PersistenceManager>
Bei nächsten Neustart wird eine Überprüfung bzw. Korrektur (Index oder Persistenz-Manager) ausgeführt. Nachdem die Konsistenzprüfung abgeschlossen ist, deaktivieren Sie die entsprechenden Einstellungen, da sonst beim Start von CRX die Konsistenzprüfung immer ausgeführt wird.
Wenn nur die Konsistenzprüfung aktiviert ist, wird eine Datei inconsistentBundleIds.txt im Arbeitsbereichsverzeichnis erstellt.
Wenn nur consistencyFix aktiviert ist, wird die Datei inconsistentBundleIds.txt gelesen und die Knoten werden korrigiert. Die Datei wird dann gelöscht, wenn alles korrigiert werden konnte.
Inkonsistenzen in einem Cluster korrigieren.
Führen Sie eine Konsistenzkorrektur in einer Clusterumgebung nur auf einem Clusterknoten aus. Starten Sie keine anderen Clusterknoten, während die Konsistenzkorrektur ausgeführt wird. Nachdem sie beendet ist, können die anderen Clusterknoten gestartet werden.
Inkonsistenzen schnell korrigieren.
Die Konsistenzprüfung untersucht alle Knoten und ist daher langsam. Ziehen Sie in Betracht, die Konsistenzprüfung auf einer Kopie des Repositorys auszuführen und dann nur die beschädigten Knoten zu reparieren, um die Wartungszeit zu reduzieren. Verwenden Sie dazu die folgenden Schritte:
- Kopieren Sie das Repository mithilfe der Online-Sicherungsfunktion.
- Führen Sie die Konsistenzprüfung und Korrektur (wie oben beschrieben) auf einer Kopie des Repository durch, wenn möglich auf einem anderen Computer.
- Sie finden die UUIDs der beschädigten Knoten in der CRX-Logdatei.
- Führen Sie die Konsistenzprüfung und Korrektur nur auf diesen Knoten im Original Repository durch.
Um die Konsistenzprüfung und Korrektur auf eine Liste von Knoten zu beschränken, fügen Sie die UUIDs dieser Knoten in zu der Konfigurationsoption „consistencyCheckUUIDs“ hinzu:
<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>
Ab CRX 2.2 können Sie diesen JVM-Parameter dem CRX-/CQ5-Start hinzufügen, um Beschädigungen zu vermeiden:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true.
Wenn Sie den CQSE-Schnellstart-Server verwenden, können Sie den Parameter zur JVM_OPTS-Variable hinzufügen, zum Beispiel:
crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
oder crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true.
Hinweis:
Die Verwendung der Systemeigenschaft validateheirarchy führt zu einer leichten Verschlechterung der Leistung von Sitzungsspeichervorgängen im Repository. Wenn Sie vorhaben, diese Funktion zu verwenden, sollten Sie zuerst einen Lasttest machen, um festzustellen, welche Auswirkung die Funktion hat. Dies trifft besonders dann zu, wenn Sie eine schreibintensive Anwendung haben.
Hinweis:
Stellen Sie sicher, dass die Tar-Optimierung deaktiviert ist, wenn die Konsistenzprüfung ausgeführt werden soll, um zu vermeiden, dass parallel die Tar-Optimierung und die Konsistenzprüfung ausgeführt werden.
Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.