Recupero da una cronologia delle versioni non funzionanti

Una cronologia delle versioni non coerente può causare il malfunzionamento di molte operazioni di CQ, tra cui la replica, il ripristino delle versioni e l'installazione dei pacchetti di contenuti.

Se la cronologia di una versione è corrotta, puoi vedere l'eccezione org.apache.jackrabbit.core.state.NoSuchItemStateException nei file di log. E, vedi la stessa cosa nelle classi di stack trace del pacchetto org.apache.jackrabbit.core.version.

Soluzione

Usa il parametro di sistema "org.apache.jackrabbit.version.recovery:"

Per risolvere il parametro, procedi come segue:

1. Installa l'ultimo hotfix CRX2.2. Puoi richiedere l'ultima hotfix CRX presentando un ticket di supporto. Segui le istruzioni per l'installazione di hotfix e assicurati di riavviare CQ dopo l'installazione.
   
2. Interrompi CQ/CRX.
3. Aggiungi il parametro jvm allo script di avvio: -Dorg.apache.jackrabbit.versione.recovery=true
4. Avvia CQ/CRX.
5. Controlla lo stato del processo java (per esempio, ps -ef | grep java) per verificare che il nuovo parametro sia utilizzato.

Quando abilitata, questa funzione cerca tutti i nodi versionabili nel repository e controlla se la cronologia delle rispettive versioni esiste.

Se non è il caso, la procedura di recupero rimuove il riferimento interrotto alla versione archiviata. In particolare il mixin mix:versionable, e le proprietà jcr:versionHistory, jcr:baseVersion, jcr:predecessors e jcr:isCheckedOu t. Permette al repository di creare un nuovo grafico di versione per il nodo, impiegando del tempo.

Se i nodi mancanti sono a livello di root, le incongruenze del workspace della versione non sono riparabili. In questo caso, è necessario partire da una nuova versione di un nuovo dataset. L'unica possibilità di recuperare i dati precedenti dalla versione è quella di utilizzare un backup. Quindi, è possibile utilizzare il pacchetto una volta che la versione è stata ripristinata.   Se è necessario rimuovere la cartella della versione (che viene ricreata automaticamente all'avvio), un contenuto importante da avere è la modalità workflow. Poi, dopo il riavvio (con il parametro jvm di cui sopra), è possibile installare un pacchetto che riporta il modello dei flussi di lavoro nella versione. Qualsiasi istanza del flusso di lavoro che non è stata completata non può essere elaborata ulteriormente in quanto le informazioni sulla versione sono collegate all'istanza del flusso di lavoro. (Vedi la relativa proprietà nel nodo di istanza del flusso di lavoro). Se manca quella versione del modello, non può continuare ad elaborarlo (è necessario correggerlo manualmente).   Prima di completare i passaggi seguenti, assicurati che tutti i flussi di lavoro siano stati completati. (Se disponi di un'istanza in esecuzione, richiede azioni extra con uno script personalizzato per resettare il riferimento alla nuova versione del modello di istanza del flusso di lavoro).

1. Interrompi l'istanza.
2. Elimina la cartella della versione e il repository/repository/index folder.
3. (Facoltativo) Aggiungi correzioni di coerenza/controllo ne workspace crx.default.xml per i dati di Tar Persistence Manager.
4. Aggiungi -Dorg.apache.jackrabbit.version.recovery=true
5. Avvia l'istanza (possono volerci diverse ore o giorni a seconda della dimensione dei dati e delle prestazioni degli I/O, quindi si consiglia di testare prima una copia.
   
6. Quando l'istanza è pronta, crea un pacchetto da /etc/workflow/models.
7. Elimina i modelli /etc/worflow/models (usando CRXDE o CRX Explorer).
8. Installa il pacchetto appena creato per ricreare i modelli di flusso di lavoro.

Nota: A partire da CRX 2.2, il parametro descritto nel seguente articolo aiuta ad evitare incongruenze.