Récupération à partir d’un historique de versions rompu

L’historique des versions incohérentes peut entraîner un grand nombre d’opérations CQ, notamment la réplication, la restauration de version et l’installation des modules de contenu.

Un historique de version rompu provoque une exception org.apache.jackrabbit.core.state.NoSuchItemStateException dans les fichiers journaux. Et vous voyez le même élément dans les classes liées à la trace de la pile du module org.apache.jackrabbit.core.version.

Solution

Utilisez le paramètre système « org.apache.jackrabbit.version.recovery: »

Pour appliquer le paramètre, procédez comme suit :

1. Installez le dernier correctif CRX2.2. Vous pouvez demander le dernier correctif CRX en soumettant un ticket au Servide de support. Suivez les instructions d'installation de correction et veillez à redémarrer le CQ après l'avoir installé.
   
2. Arrêtez CQ/CRX.
3. Ajoutez le paramètre jvm au script de démarrage : -Dorg.apache.jackrabbit.version.recovery=true
4. Démarrez CQ/CRX.
5. Vérifiez l’état du processus java (par exemple, ps -ef | grep java) pour vérifier que le nouveau paramètre est utilisé.

Lorsqu’elle est activée, cette fonction recherche tous les nœuds versionables dans le référentiel et vérifie si l’historique de version respective existe.

Si ce n’est pas le cas, la procédure de récupération supprime la référence interrompue au magasin de versions. En particulier : le mixin mix:versionable et les propriétés jcr:versionHistory, jcr:baseVersion, jcr:predecessors et jcr:isCheckedOut. Il permet au référentiel de créer le graphique de la nouvelle version pour le noeud, le temps requis.

Si les nœuds manquants sont au niveau racine, les incohérences de l’espace de travail de version ne sont pas réparables. Dans ce cas, il est nécessaire de commencer à partir d’un nouvel ensemble de données. La sauvegarde est le seul moyen de récupérer des données précédentes de la version. Vous pouvez ensuite utiliser le module une fois la version restaurée.   Si vous devez supprimer le dossier de version (qui est automatiquement recréé au démarrage), le mode de flux de production est un contenu important à posséder. Après avoir redémarré (avec le paramètre jvm ci-dessus), vous pouvez installer le module permettant de reconfigurer le modèle de flux de production dans la version. Les instances de flux de production qui ne sont pas achevées ne peuvent pas continuer à traiter les informations car les informations relatives à la version sont liées à l’instance du flux de production. (Voir la propriété associée dans le nœud de l’instance du flux de production). Si la version du modèle est manquante, elle ne peut pas continuer à le traiter (il est nécessaire de la corriger manuellement).   Avant de suivre les étapes ci-dessous, assurez-vous que tous les processus sont terminés. (Si une instance est en cours d’exécution, cela nécessite des actions supplémentaires avec un script personnalisé pour réinitialiser la référence de la version du modèle d’instance du processus vers la nouvelle version).

1. Arrêtez l’instance.
2. Supprimez le dossier de version et le dossier repository/repository/index.
3. (Facultatif) Ajoutez un correctif de cohérence et vérification dans le crx.default workspace.xml pour le gestionnaire des données de la rémanence tar.
4. Ajoutez -Dorg.apache.jackrabbit.version.recovery=true
5. Démarrez une instance (cette opération peut prendre plusieurs heures, jours, selon la taille de données et performances I/O, pensez à tester sur une copie au préalable.
   
6. Lorsque l’instance est prête, créez un module à partir de /etc/workflow/models.
7. Supprimez /etc/worflow/models (avec les explorateurs CRXDE ou CRX).
8. Installez le module que vous venez de créer pour recréer les modèles de processus.

Remarque : Depuis CRX 2.2, le paramètre décrit dans l'article suivant permet d'éviter des incohérences.