O trabalho do Sling falha com OakState0002 e erros de redefinição de ramificação no AEM
Um trabalho Sling personalizado que move ativos entre pastas falha intermitentemente com erros de confirmação JCR, como OakState0002 e falhas de redefinição de ramificação. O job processa ativos em carga simultânea usando sessões de longa duração e grandes operações de commit, resultando em falhas de commit repetidas. Para resolver o problema, refatore o manuseio de sessão e implemente a lógica de repetição.
Descrição description
Ambiente
Adobe Experience Manager as a Cloud Service (AEMaaCS)
Problema/Sintomas
-
O Trabalho personalizado do Sling
com.adidasedamprogram.core.job.MoveAssetsFromUploadToIngestionAreaJobfalha intermitentemente ao ser executado na instância do autor ao mover ativos entre pastas. -
Uma lista de pendências temporária se forma com maior profundidade da fila em
move_assets_upload_to_ingestion/queue/1..4durante os períodos de pico de assimilação. -
A atividade de trabalho apresenta picos durante períodos específicos ao processar grandes volumes de ativos, resultando em execução inconsistente.
-
Os logs de erro exibem falhas de confirmação, incluindo:
code language-none java.lang.IllegalStateException: Branch with failed reset Caused by: CommitFailedException: OakOak0100: Branch reset failed ... OakState0002: Conflicting concurrent change -
Esses erros permanecem isolados e não indicam uma interrupção em toda a plataforma, mas causam atrasos temporários no processamento de ativos.
Causa raiz
A causa raiz é o uso de sessões JCR de longa duração e grandes confirmações em carga simultânea sem manipulação de atualização e repetição para conflitos de confirmação do Oak. Isso resulta em falhas de confirmação transitórias, como OakState0002 e erros de redefinição de ramificação.
Resolução resolution
Para resolver o problema, siga as etapas abaixo:
- Refatore a implementação personalizada do Sling Job para evitar sessões JCR de longa duração usando sessões de curta duração para cada ativo ou um pequeno lote de ativos, garantindo que o escopo da sessão permaneça mínimo e reduza a disputa.
- Reduza o tamanho de cada confirmação confirmando alterações por ativo ou em lotes pequenos, em vez de executar grandes operações em massa, o que ajuda a evitar falhas de confirmação na carga simultânea.
- Implemente a lógica de repetição associada para operações de confirmação detectando falhas como OakState0002 ou erros de redefinição de ramificação, atualizando a sessão usando
session.refresh(true)e repetindo a confirmação um número limitado de vezes. - Certifique-se de que a lógica de repetição imponha limites rigorosos para evitar loops infinitos ou tentativas excessivas, mantendo a estabilidade do sistema e evitando o uso desnecessário de recursos.
- Monitore a profundidade da fila do trabalho e os registros de erros depois de aplicar essas alterações para confirmar se a frequência de conflitos de confirmação diminui e o processamento do trabalho se estabiliza.
- Nenhuma alteração na plataforma ou na infraestrutura é necessária, pois o ambiente subjacente do AEM e a integridade do container não são afetados.
Leitura relacionada
O Assets não move do carregamento para a pasta de destino no AEMaaCS