DocumentaçãoKCS da Experience Cloud

O pipeline de AEM Cloud Manager ficou preso durante a implantação em preparo devido ao conflito de ativação do pacote OSGi

Última atualização: 19 de agosto de 2026

Este artigo explica como resolver um problema em que um pipeline do Adobe Experience Manager (AEM) Cloud Manager fica preso durante a fase de Implantação em preparo, resultando em instâncias indisponíveis e erros de classe ausente devido a conflitos de ativação de pacote OSGi.

Descrição description

Ambiente

Adobe Experience Manager (AEM) as a Cloud Service (AEMaaCS) (todas as versões)

Sintomas

  • A execução do pipeline do Cloud Manager permanece presa na fase Implantar em preparo por um período estendido (mais de uma hora) sem erros ou progresso visíveis.
  • Os ambientes afetados ficam indisponíveis após a implantação.
  • As tentativas de acessar instâncias afetadas resultam em uma página de logon em branco.
  • Os logs mostram erros de classe ausente, respostas HTTP 500 ou 404 para /libs/granite/core/content/login.html e falhas de verificação de integridade.
  • Reiniciar o AEM não resolve o problema; os erros persistem após a reinicialização.
  • O problema pode afetar apenas um subconjunto de instâncias, indicando um tempo ou uma condição de corrida.

Causa

Uma implantação atualizou uma biblioteca compartilhada fundamental, acionando uma atualização da estrutura OSGi. O método de ativação de um componente personalizado executou um logon de repositório de bloqueio (JCR) durante essa atualização, causando contenção de bloqueio e deixando os pacotes dependentes no estado de metade do início. Isso resultou na paralisação do pipeline e em instâncias afetadas tornando-se indisponíveis.

Resolução resolution

Siga as etapas abaixo para resolver o problema:

  1. Identificar o(s) ambiente(s) afetado(s):

    • Revise os logs de execução de pipeline do Cloud Manager e os logs de instância do AEM para erros de classe ausente e falhas de ativação de pacote.

    • Confirme quais instâncias estão indisponíveis após a implantação.

  2. Restaurar ambientes afetados:

    • Use os backups de ambiente disponíveis para restaurar as instâncias afetadas para um estado em boas condições.

    • Valide se todas as instâncias retornam a um estado operacional e a página de logon é carregada corretamente.

  3. Revise a lógica de ativação do pacote OSGi personalizado:

    • Inspecione os componentes OSGi personalizados, especialmente aqueles com métodos onActivate() que executam logons de repositório (JCR) ou outras operações de bloqueio durante a ativação.

    • Refatore a lógica de ativação para evitar o bloqueio de chamadas ou logons de repositório durante a ativação do pacote OSGi, pois isso pode causar bloqueios ou interrupções durante atualizações da estrutura.

    • Procure padrões de código em que o logon no repositório ou as operações de longa duração sejam executados diretamente no método de ativação.

  4. Testar a implantação em um ambiente inferior:

    • Antes de implantar na produção, teste o mesmo pacote em um ambiente inferior para verificar se o problema não se repete.

  5. Monitorar implantações futuras:

    • Se ocorrer uma paralisação semelhante, colete os registros e os detalhes de execução do pipeline para análise adicional.

Verificação:

  • Confirme se todas as instâncias afetadas estão operacionais e se a página de logon é carregada conforme esperado após a restauração e as alterações de código.
recommendation-more-help
experience-cloud-kcs-help-kbarticles