RepositoryException: .lock è bloccato da un altro processo

Sintomi

In un ambiente CRX con cluster TarPM, la seguente eccezione viene lanciata all'avvio di nodi cluster CRX aggiuntivi:

ATTENZIONE com.day.crx.persistence.tar.ReplicatingTarSet.open - Non è stato possibile acquisire il blocco su /repository/shared/version/control javax.jcr.RepositoryException: la home dell'archivio /repository/shared/version/control sembra essere in uso poiché il file nominato .lock è bloccato da un altro processo.

Causa

Questa eccezione è generata da un problema di bloccaggio la cui causa principale può essere una delle seguenti:

• Un'istanza CRX che tiene il blocco su una cartella condivisa (versione, spazio di lavoro, diario o archivio) è stata chiusa in modo anomalo, lasciando dietro di sé file .lock vecchi.
• Un nodo del cluster CRX sta attualmente tenendo il bloccaggio su una cartella condivisa, ma altre istanze del cluster CRX non possono connettersi al nodo master del cluster CRX

La prima situazione è solitamente non problematica, il file vecchio .lock viene rimosso e sarà sostituito. Tuttavia, quando si utilizza una versione precedente di NFS, il file system potrebbe non rilasciare il bloccaggio dei file su questo file dopo un arresto anomalo.

Quest'ultimo è un problema, anche se la comunicazione tra uno slave e un nodo master del cluster CRX è necessaria per garantire la corretta sincronizzazione dell'accesso in scrittura all'archivio. Se un nodo slave del cluster non è in grado di connettersi al nodo master tramite la rete, presuppone che non sia in esecuzione e cerca di assumere il ruolo master.

Risoluzione

Se utilizzi una versione precedente di NFS, assicurati che tutti i processi siano interrotti e elimina manualmente tutti i file .lock. Se questo non risolve il problema, controlla il parametro indirizzo del file listener.properties all'interno della cartella condivisa che causa il problema.

Esempio:

indirizzo=192.168.1.22\:58128

Questo file viene letto da tutti i nodi (slave) del cluster CRX. L'indirizzo IP deve quindi essere raggiungibile da tutte le macchine slave, altrimenti si verifica l'eccezione menzionata.

Per impostazione predefinita, CRX utilizzerà qualsiasi interfaccia di rete e porta disponibile. È anche possibile assegnare esplicitamente un indirizzo IP e un intervallo di porte da utilizzare. Queste impostazioni devono essere impostate a livello di TarPersistenceManager sia nel repository.xml che nel 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>

Prodotti interessati:

CRX 1.4.x (in cluster)