Recuperar de un historial de versión roto

Un historial de versiones inconsistente puede causar un mal funcionamiento de muchas operaciones de CQ, incluyendo la replicación, la restauración de versiones y la instalación de paquetes de contenido.

Si se rompe el historial de una versión, verá la excepción org.apache.jackrabbit.core.state.NoSuchItemStateException en los archivos de registro. Y, usted ve lo mismo en las clases de rastreo de la pila desde el paquete org.apache.jackrabbit.core.version.

Solución

Usar el parámetro de sistema "org.apache.jackrabbit.version.recovery:"

Para aplicar la corrección, hacer lo siguiente:

1. Instalar la última versión, corrección CRX2.2. Solicitar la última corrección CRX enviando un vale a soporte. Seguir las instrucciones de instalación de la corrección y asegúrarse de reiniciar CQ después de instalarlo.
   
2. Detener CQ/CRX.
3. Añadir el parámetro jvm al script al inicio: -Dorg.apache.jackrabbit.version.recovery=true
4. Iniciar CQ/CRX.
5. Comprobar el estado del proceso java (por ejemplo, ps -ef | grep java) para verificar que se utiliza el nuevo parámetro.

Cuando está habilitada, esta característica busca todos los nodos versionables en el repositorio, y comprueba si existe el historial de versiones respectivo.

Si no es el caso, el procedimiento de recuperación elimina la referencia rota al almacén de versiones. En particular mix:versionable mixin, y propiedades jcr:versionHistory, jcr:baseVersion, jcr:predecessors and jcr:isCheckedOut. Permite al repositorio crear una nueva gráfica de versión para el nodo, el tiempo que sea necesario.

Si los nodos que faltan están en el nivel raíz, las inconsistencias del espacio de trabajo de la versión no se pueden reparar. En ese caso, es necesario empezar desde un nuevo conjunto de datos de versión nueva. La única posibilidad de recuperar los datos anteriores de la versión es utilizar una copia de seguridad. A continuación, puede utilizar el paquete una vez que se haya restaurado la versión.   Si tiene que eliminar la carpeta de la versión (que se vuelve a crear automáticamente al iniciar), un contenido importante que debe tener es el modo de flujo de trabajo. Luego, después de reiniciar (con el parámetro jvm anterior), puede instalar un paquete que vuelva a establecer el modelo de flujos de trabajo en la versión. Las instancias de flujo de trabajo que no se completan no pueden seguir procesándose ya que la información de la versión está vinculada a la instancia de flujo de trabajo. (Consultar la propiedad relacionada en el nodo de instancia de flujo de trabajo.) Si falta esa versión del modelo, no puede seguir procesándolo (es necesario arreglarlo manualmente).   Antes de completar los pasos siguientes, asegúrese de que se han completado todos los flujos de trabajo. (Si tiene una instancia en ejecución, se requieren acciones adicionales con un script personalizado para restablecer la referencia del modelo de instancia de flujo de trabajo a la nueva).

1. Detener la instancia.
2. Borrar la carpeta de versión y el repository/repository/index.
3. (Opcional) Agregar la corrección consistencia/comprobación en el crx.default workspace.xml para los datos del Tar Persistence Manager.
4. Añadir: Dorg.apache.jackrabbit.version.recovery=true
5. Iniciar la instancia (puede tardar varias horas o días dependiendo del tamaño de los datos y del rendimiento de E/S, así que considere primero realizar pruebas en una copia.
   
6. Cuando la instancia esté lista, crear un paquete desde /etc/workflow/models.
7. Borrar el /etc/worflow/models (usando el Explorador CRXDE o CRX Explorer).
8. Instalar el paquete que acaba de crear para recrear los modelos de flujo de trabajo.

Nota: A partir de CRX 2.2, el parámetro descrito en el siguiente artículo ayuda a evitar inconsistencias.