RepositoryException: .lock está bloqueado por outro processo

Sintomas

Em um ambiente CRX em cluster do TarPM, a seguinte exceção é lançada ao inicializar nós de cluster CRX adicionais:

WARN com.day.crx.persistence.tar.ReplicatingTarSet.open - Could not acquire the lock on /repository/shared/version/control javax.jcr.RepositoryException: The repository home /repository/shared/version/control appears to be in use since the file named .lock is locked by another process.

Causa

Esta exceção é lançada devido a um problema de bloqueio cuja causa raiz pode ser uma das seguintes:

• Uma instância do CRX que mantém o bloqueio em uma pasta compartilhada (versão, espaço de trabalho, diário ou repositório) foi desligada de forma anormal, deixando para trás arquivos.lock obsoletos.
• Um nó de cluster CRX está atualmente mantendo o bloqueio em uma pasta compartilhada, mas outras instâncias de cluster CRX não podem se conectar ao nó do cluster CRX principal.

A primeira situação é geralmente não causa problemas. O arquivo .lock obsoleto é removido e substituído. No entanto, quando uma versão mais antiga do NFS é usada, o sistema de arquivos pode não liberar o bloqueio desse arquivo após uma falha.

Isso é um problema, já que a comunicação entre um nó de cluster CRX subordinado e mestre é necessária para garantir a sincronização adequada do acesso de gravação ao repositório. Se um nó de cluster subordinado não puder se conectar ao nó do cluster mestre através da rede, ele vai pressupor que o mestre não está em execução e tentará assumir a função.

Resolução

Ao usar uma versão mais antiga do NFS, assegure-se de que todos os processos estejam parados e exclua manualmente todos os arquivos .lock. Se isso não resolver o problema, verifique o parâmetro address do arquivo listener.properties dentro da pasta compartilhada que causa o problema.

Exemplo:

address=192.168.1.22\:58128

Este arquivo é lido por todos os nós do cluster CRX (subordinado). O endereço IP deve, portanto, estar acessível para todas as máquinas subordinadas. Caso contrário, a exceção ocorrerá.

Por padrão, o CRX usa qualquer interface de rede e porta disponíveis. Também é possível atribuir explicitamente um endereço IP e um intervalo de portas a ser usado. Essas configurações devem ser definidas no nível TarPersistenceManager em repository.xml e workspace.xml:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> ... <param name="bindAddress" value="192.168.1.10" /> <param name="portList" value="9100-9110" /> </PersistenceManager>

Aplica-se

CRX1.4.x (em cluster)