Sintomi
WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId - Unknown parent node with id ...ERROR ... failed to read bundle: ...
Causa
Questi problemi possono avere molteplici cause. Le cause possibili (a seconda della versione CRX) sono:
- Modifica simultanea utilizzando la stessa sessione: https://issues.apache.org/jira/browse/JCR-2456
- Il nodo spostato scompare dopo l'aggiornamento: https://issues.apache.org/jira/browse/JCR-1883
La causa più comune è la modifica simultanea utilizzando la stessa sessione. In questo caso, il file CRX error.log probabilmente contiene almeno una ConcurrentModificationException.
Analisi, risoluzione
Questi sintomi indicano che l'indice (ed eventualmente anche il workspace) potrebbe essere incoerente.
Di solito, l'impatto di un'incoerenza è basso. Un problema è che il file di log è pieno di messaggi di errore a causa di un'incoerenza.
Tipi di incongruenze
- Figlio orfano
- Messaggio di errore: NodeState CHILD_UUID fa riferimento a un genitore inesistente PARENT_UUID
- Messaggio di controllo di coerenza: Controllo di coerenza: Non riparabile: Il nodo
CHILD_UUID ha un genitore sconosciuto:
PARENT_UUID (ConsistencyCheck.java, riga 116) - Soluzione attuale: Utilizza la console CRX (vedi articolo)
- Genitore che fa riferimento a un figlio inesistente
- Messaggio di errore: NodeState PARENT_UUID fa riferimento a un figlio inesistente {}CHILD_NAME con id CHILD_UUID
- Soluzione attuale: il controllo di coerenza/riparazione dovrebbe risolvere il problema
- Un figlio fa riferimento a un genitore non valido
- Messaggio di errore: ChildNode ha un quid genitore non valido: INVALID_PARENT_UUID (invece di VALID_PARENT_UUID)
- Soluzione attuale: Utilizza la console CRX (vedi articolo)
- Genitore che non fa riferimento al figlio esistente
- Messaggio di errore: javax.jcr.ItemNotFoundException: non è riuscito a costruire il percorso di CHILD_UUID: PARENT_UUID non ha una voce figlio per CHILD_UUID
- Soluzione attuale: Utilizza la console CRX (vedi articolo)
- Il nodo esiste
- Messaggio di errore: javax.jcr.ItemExistsException: <node_path> at org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:766)
- Soluzione attuale: il controllo di coerenza/riparazione dovrebbe risolvere il problema
- Incoerenza dell'indice di ricerca
- Messaggio di errore: WARN NodeIteratorImpl: Eccezione per il recupero del nodo con UUID: 003171fe-e2e8-457b-a3af-f74eed12c1b9: javax.jcr.ItemNotFoundException: 003171fe-e2e8-457b-a3af-f74eed12c1b9
- Soluzione attuale: Ricrea l'indice di ricerca o esegui il controllo di coerenza dell'indice di ricerca e correggilo
- Incoerenza della ricerca
- Messaggio di errore: "Causato da: javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496" where "org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getNode" può essere visto nella traccia dello stack.
- Soluzione corrente: controlla questo adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix">ricerca la coerenza degli indici e correggila
- Incoerenza relativa alla versione
- Lo stack di messaggi di errore mostra che è correlato al codice org.apache.jackrabbit.core.version.internalXAVersionManager
- Soluzione attuale: controlla questo articolo
- File non trovato
- Messaggio di errore: ERROR TarPersistenceManager: Non sono riuscito a leggere il bundle: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
java.io.IOException: File not found: nnnnn - Soluzione corrente: controlla se riesci a trovare quel file in un backup (data_nnnnn.tar), oppure rimuovi l'index_*.tar per ricostruirlo al riavvio.
- Messaggio di errore: ERROR TarPersistenceManager: Non sono riuscito a leggere il bundle: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
Riparazione dell'indice di ricerca
Le incongruenze dell'indice di ricerca possono verificarsi a causa di quanto segue:
- Spegnimento non pulito del processo java durante un'operazione di scrittura. Questo sarebbe un kill -9 in Linux o Unix e un task manager di processo kill in Windows OS.
- Alcuni vecchi bug in CRX che sono stati corretti nelle ultime hotfix di CQ e CRX (per CRX2.2, 2.3 e 2.4). Per prevenirli, dovresti aver installato le ultime hotfix di CRX per evitare tali problemi. Se pensi di non avere l'ultimo hotfix, invia un ticket di supporto al supporto Adobe per richiederlo.
Ci sono due modi per correggere le incongruenze dell'indice di ricerca:
- Esegui un controllo di coerenza dell'indice di ricerca e correggi
- Ricrea il tuo indice di ricerca
Ricerca Controllo e correzione della coerenza dell'indice
All'avvio è possibile eseguire un controllo della coerenza dell'indice. Nel workspace.xml aggiungi due parametri nell'elemento <SearchIndex class="...">:
<param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/>
Un terzo parametro controlla se gli errori devono essere riparati o se devono essere registrati soltanto:
<param name="autoRepair" value="false"/> <!-- default is true -->
Esempio
<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>
Ricrea il tuo indice di ricerca
Ricreare l'indice di ricerca risolverà tutte le incongruenze dello stesso. Tuttavia, ci vuole molto più tempo del controllo e correzione della coerenza dell'indice di ricerca. A causa di questo, fai particolare attenzione quando pianifichi la ricostruzione di un indice di ricerca e se non puoi permetterti periodi di inattività, considera di fare un controllo e correggere invece.
Pianificazione della ricostruzione dell'indice
Poiché il tempo necessario per ricostruire l'indice dipende da molti fattori diversi (come il numero totale dei nodi, le dimensioni dei file degli elementi e i tipi di file degli elementi), dovresti prima testare la ricostruzione in un ambiente non di produzione. Utilizza il test di non produzione per calcolare la durata di una finestra di interruzione della produzione. I piccoli repository nel formato 2-10 GB possono richiedere da 30 minuti a 6 ore e quelli più grandi possono richiedere da 6 ore a 2 giorni.
Come ricostruire l'indice
Per ricostruire l'indice di ricerca, procedi come segue:
- Arrsta CRX (o CQ)
- Esegui il backup e cancella le seguenti directory nel tuo repository: crx-quickstart/repository/workspaces/crx.default/index/ e crx-quickstart/repository/repository/index/
- Avvia CRX (o CQ), questo inizierà la ricostruzione. In CRX2.2 monitorare i logs/crx/error.log e in CRX2.3 monitorare i logs/error.log per visualizzare i progressi. Si può dire che l'indicizzazione è fatta quando l'istanza CRX è accessibile.
Controllo e correzione della coerenza di Workspace Persistence Manager
Se questo non aiuta e stampa errori che non possono essere riparati, è probabile che i dati del workspace siano incoerenti.
I responsabili della persistenza possono controllare la coerenza del repository e risolvere i problemi all'avvio. Per abilitare il controllo di coerenza e risolvere automaticamente i problemi, aggiungi i seguenti parametri nel repository.xml e nel workspace.xml all'interno di ogni elemento <PersistenceManager class="...">, e riavvia CRX.
In un'installazione predefinita di CQ5.2.X questi file si trovano in crx-quickstart/repository/workspaces/*/workspace.xml e crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.
In CQ5.3, repository.xml può essere trovato sotto crx-quickstart/repository/repository.xml invece.
Esempio
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
Il controllo/correzione (index o persistence manager) verrà eseguito al prossimo avvio. Al termine della verifica della coerenza, disattiva le impostazioni pertinenti, altrimenti la verifica della coerenza viene sempre eseguita all'avvio di CRX.
Se è abilitato solo consistencyCheck, viene creato un file inconsistentBundleIds.txt nella cartella del workspace.
Se solo consistencyFix è abilitato, allora il file inconsistentBundleIds.txt viene letto, e questi nodi sono corretti. Il file viene poi cancellato se tutto può essere risolto.
Correggere le incongruenze in un cluster
Quando esegui un fix di coerenza in un ambiente cluster, eseguilo solo su un nodo cluster. Non avviare altri nodi del cluster mentre la correzione della consistenza è in esecuzione. Una volta terminato, è possibile avviare gli altri nodi del cluster.
Correzione rapida delle incongruenze
Il controllo di coerenza scansiona tutti i nodi ed è quindi lento. Per ridurre il tempo di manutenzione, considera l'esecuzione del controllo di coerenza su una copia del repository, e poi basta correggere i nodi che sono corrotti. Procedi come segue:
- Copia il repository utilizzando la funzione di backup online
- Esegui il controllo di coerenza e correggi (come descritto sopra) sulla copia del repository, possibilmente su una macchina diversa
- Nel file di log CRX, trovare gli UUID dei nodi corrotti
- Nel repository originale, eseguire il controllo di coerenza e correggere solo quei nodi
Per limitare il controllo di coerenza e correggere un elenco di nodi, aggiungi gli UUID di tali nodi nell'opzione di configurazione "consistencyCheckUUIDs":
Esempio
<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>
Previeni la corruzione dei depositi
A partire da CRX 2.2, è possibile aggiungere questo parametro jvm all'avvio di CRX/CQ5 per prevenire i danni:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true
Se utilizzi il server CQSE quickstart, è possibile aggiungere il parametro alla variabile JVM_OPTS, per esempio:
crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
o crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
L'uso della proprietà del sistema validateheirarchy provoca un leggero peggioramento delle prestazioni delle operazioni di salvataggio delle sessioni nel repository. Quando si pianifica l'utilizzo di questa funzione, si consiglia di effettuare prove di carico in anticipo per vedere quale impatto abbia. Si applica in particolare se disponi di un'applicazione che richiede molta scrittura.
Assicurati di disabilitare l'ottimizzazione tar quando il controllo di coerenza è pianificato per evitare di eseguire l'ottimizzazione tar e il controllo di coerenza in parallelo.
Versioni interessate
1.X, 2.X