La tâche Sling échoue avec OakState0002 et des erreurs de réinitialisation de branche dans AEM
Une tâche Sling personnalisée qui déplace des ressources entre des dossiers échoue par intermittence avec des erreurs de validation JCR telles que OakState0002 et des échecs de réinitialisation de branche. La tâche traite les ressources en charge simultanée à l’aide de sessions de longue durée et d’opérations de validation volumineuses, ce qui entraîne des échecs de validation répétés. Pour résoudre le problème, refactorisez la gestion des sessions et implémentez la logique de reprise.
Description description
Environnement
Adobe Experience Manager as a Cloud Service (AEMaaCS)
Problème/Symptômes
-
L’
com.adidasedamprogram.core.job.MoveAssetsFromUploadToIngestionAreaJobde tâche Sling personnalisée ne s’exécute pas par intermittence sur l’instance de création lors du déplacement de ressources entre des dossiers. -
Une liste d’attente temporaire se forme avec une profondeur de file d’attente accrue en
move_assets_upload_to_ingestion/queue/1..4pendant les périodes d’ingestion de pointe. -
L’activité de tâche culmine pendant des périodes spécifiques lors du traitement d’un grand volume de ressources, ce qui entraîne une incohérence dans l’exécution.
-
Les journaux d’erreurs affichent les échecs de validation, notamment :
code language-none java.lang.IllegalStateException: Branch with failed reset Caused by: CommitFailedException: OakOak0100: Branch reset failed ... OakState0002: Conflicting concurrent change -
Ces erreurs restent isolées et n’indiquent pas de panne à l’échelle de la plateforme, mais entraînent des retards temporaires dans le traitement des ressources.
Cause première
La cause principale est l’utilisation de sessions JCR de longue durée et de validations volumineuses avec une charge simultanée, sans gestion des actualisations et des reprises pour les conflits de validation Oak. Cela entraîne des échecs de validation transitoires tels que OakState0002 et des erreurs de réinitialisation de branche.
Résolution resolution
Pour résoudre ce problème, procédez comme suit :
- Refactorisez l’implémentation de la tâche Sling personnalisée pour éviter les sessions JCR de longue durée en utilisant des sessions de courte durée pour chaque ressource ou un petit lot de ressources, en veillant à ce que la portée de la session reste minimale et réduise les conflits.
- Réduisez la taille de chaque validation en validant les modifications par ressource ou par petits lots au lieu d’effectuer des opérations en bloc volumineuses, ce qui permet d’éviter les échecs de validation sous une charge simultanée.
- Implémentez une logique de reprise limitée pour les opérations de validation en détectant les échecs, tels que les erreurs OakState0002 ou de réinitialisation de branche, en actualisant la session à l’aide de
session.refresh(true)et en réessayant la validation un nombre limité de fois. - Assurez-vous que la logique de reprise applique des limites strictes pour empêcher les boucles infinies ou les reprises excessives, tout en maintenant la stabilité du système et en évitant l’utilisation inutile des ressources.
- Surveillez la profondeur de la file d’attente de la tâche et les journaux d’erreurs après l’application de ces modifications pour confirmer que la fréquence des conflits de validation diminue et que le traitement des tâches se stabilise.
- Aucune modification de plateforme ou d’infrastructure n’est requise, car l’environnement AEM sous-jacent et l’intégrité des conteneurs ne sont pas impliqués.
Lecture connexe
Assets ne passe pas du chargement au dossier cible dans AEMaaCS