AEM Cómo depurar SegmentNotFoundException cuando se informa de un problema en la versión 6.x de la
AEM Este artículo le ayuda a comprender cómo depurar SegmentNotFoundException cuando se informa de un problema en la versión 6.x al volver a la última revisión buena conocida del almacén de segmentos.
Descripción description
Entorno
Experience Manager 6.x
Problema/Síntomas
El registro de errores muestra una excepción SegmentNotFound, como en el ejemplo siguiente:
org.apache.jackrabbit.oak.segment.SegmentNotFoundException: Segment d2c720c4-c146-4ab1-ac37-542aad93c33f not found at
org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:602) at
org.apache.jackrabbit.oak.segment.file.FileStore$8.call(FileStore.java:542) at
org.apache.jackrabbit.oak.segment.SegmentCache.getSegment(SegmentCache.java:95) at
org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:542) at
org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:125) at
org.apache.jackrabbit.oak.segment.Record.getSegment(Record.java:70) at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:424) at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433) at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:391) at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:608) at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeChanged(EditorDiff.java:148) at
org.apache.jackrabbit.oak.segment.MapRecord$3.childNodeChanged(MapRecord.java:442) at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:490) at
org.apache.jackrabbit.oak.segment.MapRecord.compare(MapRecord.java:433) at
org.apache.jackrabbit.oak.segment.SegmentNodeState.compareAgainstBaseState(SegmentNodeState.java:608) at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:52) at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:695) at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.runWhenPermitted(AsyncIndexUpdate.java:543) at
org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:402) at
org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:118) at
org.quartz.core.JobRunShell.run(JobRunShell.java:202) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at
java.lang.Thread.run(Thread.java:745)
Resolución resolution
Pasos a resolver
Existen dos métodos para solucionar el problema y eliminar las incoherencias en el repositorio
Volver a la última revisión buena conocida del almacén de segmentos.
Primero, utilice la herramienta oak run, que es un jar ejecutable[ 1] que contiene todo lo necesario para una instalación sencilla de Oak y realizar operaciones relacionadas con oak.
El modo de ejecución de comprobación de oak-run se puede utilizar para determinar la última revisión buena conocida de un almacén de segmentos. Esto se puede usar para revertir manualmente un almacén de segmentos corrupto a su última revisión buena.
Precaución: este proceso hará retroceder los datos del sistema a un momento anterior. Si desea evitar la pérdida de cambios en su sistema, puede probar la opción B que aparece a continuación.
Para realizar la comprobación y restauración:
-
Descargue una versión de oak-run que coincida con su versión del núcleo de Oak desde https://mvnrepository.com/artifact/org.apache.jackrabbit/oak-run
-
Para revertir un almacén de segmentos corrupto a su último estado bueno, cambie al directorio de trabajo de CQ (el que contiene la carpeta crx-quickstartfolder) y haga una copia de seguridad de todos los archivos en/crx-quickstart/repository/segmentstore/.
-
Realice la comprobación de consistencia,
java -Xmx6000m -jar oak-run-*.jar check —bin=-1 /path/to/crx-quickstart/repository/segmentstore
Esto busca hacia atrás en las revisiones hasta encontrar una consistente:
Busque un mensaje como el siguiente:
code language-none main INFO o.a.j.o.p.s.f.t.ConsistencyChecker - Found latest good revision afdb922d-ba53-4a1b-aa1b-1cb044b535cf:234880 -
Revierta el repositorio a esta revisión editando/crx-quickstart/repository/segmentstore/journal.log y eliminando todas las líneas después de la línea que contiene la última revisión buena.
-
Eliminar todo.Archivos /crx-quickstart/repository/segmentstore/*.bak.
-
Ejecute la limpieza de puntos de comprobación para eliminar los puntos de comprobación huérfanos mediante el siguiente comando:
code language-none java -Xmx6000m -jar oak-run-*.jar checkpoints /path/to/crx-quickstart/repository/segmentstore rm-unreferenced -
Finalmente, compacte el repositorio:
java -Xmx6000m -jar oak-run-*.jar compact /path/to/crx-quickstart/repository/segmentstore/
Puede haber casos en los que la comprobación de ejecución de Oak no encuentre la revisión correcta y se obtenga "ConsistencyChecker - No se encontró ninguna revisión buena" al ejecutar el comando de comprobación.
Cómo corregir los daños al encontrar "ConsistencyChecker - No se encontró una buena revisión" en la comprobación de coherencia
Quite manualmente los nodos dañados.
AEM Puede hacer lo siguiente en las configuraciones de TarMK, las configuraciones de TarMK sin FileDatastore configurado y las situaciones en las que los binarios están dañados.
Precaución: el procedimiento siguiente está destinado a usuarios avanzados. Al eliminar los nodos corruptos, debe asegurarse de que no sean nodos del sistema (como /home, /jcr:system, etc) Si son nodos del sistema, debe asegurarse de que puede restaurarlos. AEM Consulte con el equipo de atención al cliente de la para obtener ayuda con los pasos documentados aquí si no está seguro.
-
Detenga AEM.
-
Utilice la consola de ejecución de Oak y cargue el script groovy childCount para identificar los nodos corruptos en el almacén de segmentos:
Cargue el shell de la consola oak-run:
code language-none java -jar oak-run-*.jar console crx-quickstart/repository/segmentstoreEjecute los dos comandos siguientes en el shell para cargar el script y ejecutarlo:
code language-none :load https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy countNodes(session.workingNode)Esto da como resultado la siguiente salida que indica la ruta a los nodos corruptos:
code language-none 21:21:42.029 main ERROR o.a.j.o.p.segment.SegmentTracker - Segment not found: 63ae05a4-b506-445c-baa2-cfa1b13b6e2f. Creation date delta is 3 ms. warning unable to read node /content/dam/test.txt/jcr:content/renditions/original/jcr:contentEn algunos casos, el problema está vinculado a las propiedades binarias y el script groovy childCount no puede localizar ningún nodo dañado. En estos casos, puede usar el siguiente comando en su lugar, que leerá los primeros 1024 bytes de cada binario encontrado durante el recorrido (tenga en cuenta que este comando será más lento y solo debe usarse cuando el anterior no devuelva los resultados esperados):
code language-none countNodes(session.workingNode,true) -
Elimine todos los nodos corruptos identificados en la lista de salida del último comando utilizando rmNodes.groovy
Cargue el shell de la consola oak-run usando el siguiente comando:code language-none java -jar oak-run-*.jar console crx-quickstart/repository/segmentstoreCargue el script groovy:
code language-none :load https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovyEjecute el comando rmNode para eliminar el nodo corrupto y reemplace /path/to/corrupto/node por la ruta al nodo corrupto que necesita eliminar.
code language-none rmNode(session, "/path/to/corrupt/node")donde la ruta del nodo corrupto es la ruta obtenida en el paso 2, por ejemplo: "/content/dam/test.txt/jcr:content/renditions/original/jcr:content/"
Nota: Cuando use la versión 1.6.13 y posteriores de oak-run.jar, establezca el parámetro JVM —read-write si encuentra un error como:
code language-none / rmNode(session,"/path/to/corrupt/node") Removing node /path/to/corrupt/node ERROR java.lang.UnsupportedOperationException: Cannot write to read-only store at org.apache.jackrabbit.oak.segment.SegmentWriterBuilder$1.execute (SegmentWriterBuilder.java:171) at org.apache.jackrabbit.oak.segment.SegmentWriter.writeNode (SegmentWriter.java:318) at org.apache.jackrabbit.oak.segment.SegmentNodeBuilder.getNodeState (SegmentNodeBuilder.java:111) at org.apache.jackrabbit.oak.segment.SegmentNodeStore$Commit.init (SegmentNodeStore.java:581) at org.apache.jackrabbit.oak.segment.SegmentNodeStore.merge (SegmentNodeStore.java:333) at org.apache.jackrabbit.oak.spi.state.NodeStore$merge.call (Unknown Source) at groovysh_evaluate.rmNode (groovysh_evaluate:11) -
Repita el paso 3 para todos los nodos del paso 2
Este comando rmNode anterior debería devolver true para la ruta corrupta, lo que significa que la ha eliminado. Asegúrese de que estas tres rutas corruptas encontradas se hayan eliminado volviendo a ejecutar el comando rmNode en esas rutas. La siguiente ejecución debería devolver "false".
Si ve que las mismas rutas aún están en el repositorio, use la versión parcheada del jar de oak-run, es decir oak-run-1.2.18-NPR-17596. Esta versión de jar omite los binarios ilegibles en la compactación, sustituyéndolos por binarios de 0 bytes y registrando la excepción y la ruta en syserr. El repositorio compactado resultante debería pasar la comprobación de oak-run y el script de recuento de nodos, y también debería poder compactarlo de nuevo usando un oak-run no parcheado. -
Realice una limpieza de puntos de comprobación enumerando los siguientes puntos. Si hay más de un punto de comprobación, límpielos:
code language-none nohup java -Xmx4096m -jar oak-run-1.2.18.jar checkpoints /app/AEM6/author/crx-quickstart/repository/segmentstore rm-allnohup.out -
Ejecute una compactación sin conexión. Si no sabe cómo ejecutar la compactación sin conexión, vea aquí.
-
Inicie el servidor y espere a que se complete la indexación.
Causa
Una excepción SegmentNotFoundException en el registro de errores significa que un segmento ya no está presente, aunque aparentemente alguien intente obtener acceso a él. Existen, en general, tres causas raíz diferentes para esto: el segmento se ha eliminado mediante intervención manual (por ejemplo, rm -rf /), el segmento se ha eliminado mediante la recolección de basura de revisiones o el segmento no se puede encontrar debido a algún error en el código.