Histórico de versão quebrado faz com que as operações do CQ funcionem incorretamente

O histórico inconsistente da versão pode causar o mau funcionamento de muitas operações do CQ, incluindo replicação, restauração de versão e instalação do pacote de conteúdo.

Se um histórico de versão está quebrado, você vê a exceção org.apache.jackrabbit.core.state.NoSuchItemStateException nos arquivos de log. E vê a mesma coisa nas classes de rastreamento de pilha do pacote org.apache.jackrabbit.core.version.

Solução

Use o parâmetro do sistema "org.apache.jackrabbit.version.recovery:"

Para aplicar o parâmetro, faça o seguinte:

  1. Instale o hot fix mais recente do CRX2.2. Solicite o hot fix mais recente do CRX enviando um chamado de suporte. Siga as instruções de instalação do hot fix e certifique-se de reiniciar o CQ após instalá-lo.
  2. Interrompa o CQ/CRX.
  3. Adicione o parâmetro jvm ao script de inicialização: -Dorg.apache.jackrabbit.version.recovery=true
  4. Inicie o CQ/CRX.
  5. Verifique o status do processo java (por exemplo, ps -ef | grep java) para verificar se o novo parâmetro está em uso.
Quando ativado, esse recurso procura todos os nós com versão no repositório e verifica se o respectivo histórico de versão existe.

Se não for o caso, o procedimento de recuperação remove a referência quebrada ao armazenamento de versão. Especificamente, o mixin mix:versionable e as propriedades jcr:versionHistory, jcr:baseVersion, jcr:predecessors e jcr:isCheckedOut. Isso permite que o repositório crie um novo gráfico de versão para o nó quando for necessário.

Se os nós ausentes estão no nível raiz, não é possível reparar as inconsistências da versão do espaço de trabalho. Nesse caso, é necessário criar um novo conjunto de dados da nova versão. Sua única chance de recuperar dados anteriores da versão é usar um backup. Então, é possível usar o pacote quando a versão for restaurada.
 
Se for necessário remover a pasta da versão (que é automaticamente recriada na inicialização), é importante ter o modo de fluxo de trabalho. Em seguida, após reiniciar (com o parâmetro jvm acima), é possível instalar um pacote que define o modelo de fluxos de trabalho novamente para a versão. Todas as instâncias de fluxo de trabalho não concluídas não podem ser processadas posteriormente, pois as informações da versão estão vinculadas à instância do fluxo de trabalho. (Consulte a propriedade relacionada no nó da instância do fluxo de trabalho.) Se essa versão do modelo estiver faltando, ela não poderá continuar sendo processada (é necessário corrigi-la manualmente).
 
Antes de concluir as etapas abaixo, verifique se todos os fluxos de trabalho estão concluídos. (Se há uma instância em execução, ela requer ações adicionais com um script personalizado para redefinir a referência de versão do modelo de instância do fluxo de trabalho para a nova).
  1. Pare a instância.
  2. Exclua a pasta da versão e a pasta repository/repository/index.
  3. (Opcional) Adicione uma correção de consistência/verificação a crx.default workspace.xml para os dados do Gerenciador de persistência de tar.
  4. Adicione -Dorg.apache.jackrabbit.version.recovery=true
  5. Inicie a instância (pode levar várias horas ou dias dependendo do tamanho dos dados e das performances de E/S, portanto, considere testar em uma cópia primeiro.
  6. Quando a instância estiver pronta, crie um pacote em /etc/workflow/models.
  7. Exclua /etc/worflow/models (usando o CRXDE ou o CRX Explorer).
  8. Instale o pacote recém-criado para recriar os modelos de fluxo de trabalho.

Nota: a partir do CRX 2.2, o parâmetro descrito no artigo a seguir ajuda a evitar inconsistências.

Esta obra está licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online