Pipeline AEM Cloud Manager bloqué pendant le déploiement dans l’environnement intermédiaire en raison d’un conflit d’activation du bundle OSGi
Cet article explique comment résoudre un problème où un pipeline Cloud Manager Adobe Experience Manager (AEM) est bloqué pendant la phase de déploiement dans l’environnement d’évaluation, ce qui entraîne des instances indisponibles et des erreurs de classe manquante en raison de conflits d’activation de bundle OSGi.
Description description
Environnement
Adobe Experience Manager (AEM) as a Cloud Service (AEMaaCS) (toutes les versions)
Symptômes
- L’exécution du pipeline Cloud Manager reste bloquée dans la phase de déploiement dans l’environnement intermédiaire pendant une période prolongée (plus d’une heure), sans erreurs visibles ni progression.
- Les environnements affectés ne sont plus disponibles après le déploiement.
- Les tentatives d’accès aux instances affectées entraînent une page de connexion vierge.
- Les journaux affichent les erreurs de classe manquante, les réponses HTTP 500 ou 404 pour les
/libs/granite/core/content/login.htmlet les échecs de vérification de l’intégrité. - Le redémarrage d’AEM ne résout pas le problème ; les erreurs persistent après le redémarrage.
- Le problème peut uniquement affecter un sous-ensemble d’instances, indiquant une condition de minutage ou de concurrence.
Cause
Un déploiement a mis à jour une bibliothèque partagée fondamentale, déclenchant une actualisation du framework OSGi. La méthode d’activation d’un composant personnalisé a effectué une connexion au référentiel de blocage (JCR) pendant cette actualisation, provoquant des conflits de verrouillage et laissant les lots dépendants à l’état semi-démarré. Cela entraînait le blocage du pipeline et les instances affectées devenaient indisponibles.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
-
Identifier les environnements affectés :
-
Consultez les journaux d’exécution du pipeline Cloud Manager et les journaux des instances AEM pour identifier les erreurs de classe manquante et les échecs d’activation des lots.
-
Vérifiez quelles instances ne sont pas disponibles après le déploiement.
-
-
Restaurer le(s) environnement(s) affecté(s) :
-
Utilisez les sauvegardes d’environnement disponibles pour restaurer les instances affectées à un état adapté.
-
Vérifiez que toutes les instances redeviennent opérationnelles et que la page de connexion se charge correctement.
-
-
Examinez la logique d’activation du lot OSGi personnalisé :
-
Inspectez les composants OSGi personnalisés, en particulier ceux qui utilisent des méthodes
onActivate()qui effectuent des connexions au référentiel (JCR) ou d’autres opérations de blocage pendant l’activation. -
Refactorisez la logique d’activation pour éviter de bloquer les appels ou les connexions au référentiel lors de l’activation du lot OSGi, car cela peut entraîner des blocages ou des blocages lors des actualisations du framework.
-
Recherchez les modèles de code pour lesquels la connexion au référentiel ou les opérations de longue durée sont effectuées directement dans la méthode d’activation.
-
-
Tester le déploiement dans un environnement inférieur :
- Avant de procéder au déploiement en production, testez le même package dans un environnement inférieur pour vérifier que le problème ne se reproduit pas.
-
Surveillez les déploiements futurs :
- Si un blocage similaire se produit, collectez les journaux et les détails d’exécution du pipeline pour une analyse plus approfondie.
Vérification :
- Vérifiez que toutes les instances affectées sont opérationnelles et que la page de connexion se charge comme prévu après la restauration et les modifications de code.