AEM 6.4 a atteint la fin de la prise en charge étendue et cette documentation n’est plus mise à jour. Pour plus d’informations, voir notre période de support technique. Rechercher les versions prises en charge here.
Cette page fournit des informations sur la manière de résoudre les problèmes de réplication.
La réplication (réplication non inverse) échoue pour une raison quelconque.
Il existe plusieurs raisons pour lesquelles la réplication échoue. Cet article explique l’approche que vous pouvez adopter lors de l’analyse de ces problèmes.
Les réplications sont-elles déclenchées en cliquant sur le bouton d’activation ? Dans le cas contraire, procédez comme suit :
Les réplications sont-elles mises en file d’attente dans les files d’attente de l’agent de réplication ?
Vérifiez si c’est le cas en vous rendant sur /etc/replication/agents.author.html, puis cliquez sur les agents de réplication pour vérifier les éléments suivants.
Si une ou plusieurs files d’attente sont bloquées :
Le statut de la file d’attente est-t-il blocked ? Le cas échéant, l’instance de publication n’est-elle pas en cours d’éxécution ou a-t-elle cessé totalement de répondre ? Vérifiez l’instance de publication pour voir ce qui ne va pas avec elle (c’est-à-dire vérifiez les journaux et vérifiez s’il existe une erreur OutOfMemory ou un autre problème). Si c'est généralement lent, prenez les images mémoire de threads et analysez-les.
Le statut de la file d’attente est-t-il Queue is active - # pending ? Fondamentalement, la tâche de réplication peut être bloquée dans une lecture de socket en attente de réponse de l’instance de publication ou du dispatcher. Cela peut signifier que l’instance de publication ou le dispatcher est en charge élevée ou coincé dans un verrou. Dans ce cas, prenez les thread dumps de l’auteur et de la publication.
Si toutes les files d’attente de l’agent sont bloquées
Il est possible qu’un certain élément du contenu ne puisse pas être sérialisé sous /var/replication/data à cause de la corruption du référentiel ou d’un autre problème. Vérifiez les journaux /error.log pour détecter une erreur correspondante. Pour supprimer un élément de réplication défectueux, procédez comme suit :
Il se peut qu’il y ait un problème avec les files d’attente de tâche de structure sling eventing. Essayez de redémarrer le lot org.apache.sling.event dans le répertoire /system/console.
Il se peut que le traitement des tâches soit complètement désactivé. Vous pouvez vérifier cela sous la console Felix dans l’onglet Sling Eventing. Vérifiez s’il s’affiche - Événement Apache Sling (LE TRAITEMENT DES TÂCHES EST DÉSACTIVÉ).
Il se peut également que la configuration DefaultJobManager se trouve dans un état incohérent. Cela peut se produire lorsqu’une personne modifie manuellement la configuration "Apache Sling Job Event Handler" via la console OSGiconsole (par exemple, désactivez et réactivez la propriété "Job Processing Enabled" et enregistrez la configuration).
Création d’un fichier replication.log
Il peut parfois s’avérer très utile de définir toutes les journaux de réplication à ajouter dans un fichier journal distinct au niveau DEBUG. Pour ce faire :
Accédez à https://host:port/system/console/configMgr
et connectez-vous en tant qu’administrateur.
Identifiez la fabrique Enregistreur de connexion Sling Apache et créez une instance en cliquant sur le bouton + à droite de la configuration de la fabrique. Cela créera un nouveau journal de journalisation.
Définissez la configuration comme suit :
Si vous pensez que le problème est lié de quelque manière que ce soit à sling eventing/jobs, vous pouvez également ajouter ce package java sous categories:org.apache.sling.event.
Parfois, il peut être judicieux de suspendre la file d’attente de réplication afin de réduire la charge sur le système de création, sans la désactiver. Actuellement, cela n’est possible que par une erreur de configuration temporaire d’un port non valide. À partir de la version 5.4, vous pouvez voir un bouton de pause dans la file d’attente de l’agent de réplication, qui présente certaines limites.
Les autorisations de page ne sont pas répliquées car elles sont stockées sous les nœuds auxquels l’accès est accordé, pas avec l’utilisateur.
En règle générale, les autorisations de page ne doivent pas être répliquées de l’auteur vers la publication et ne le sont pas par défaut. En effet, les droits d’accès doivent être différents dans ces deux environnements. Par conséquent, il est recommandé de configurer les listes de contrôle d’accès lors de la publication séparément de l’auteur.
Dans certains cas, la file d’attente de réplication est bloquée lors de la tentative de réplication des informations sur les espaces de noms depuis l’instance d’auteur vers l’instance de publication. Ce problème se produit car l’utilisateur de la réplication ne dispose pas du privilège jcr:namespaceManagement
. Pour éviter ce problème, vérifiez les points suivants :
jcr:namespaceManagement
au niveau du référentiel. Vous pouvez accorder le privilège comme suit :http://localhost:4502/crx/de/index.jsp
) en tant qu’administrateur.jcr:namespaceManagement
dans la liste des privilèges.