Symptome
In einer TarPM CRX-Clusterumgebung wird folgende Ausnahme ausgelöst, wenn weitere CRX-Clusterknoten gestartet werden:
WARN com.day.crx.persistence.tar.ReplicatingTarSet.open- konnte die Sperre auf /repository/shared/version/control javax.jcr.RepositoryException nicht erfassen: Das Repository-Home /repository/shared/version/control scheint verwendet worden zu sein, seit die Datei .lock durch einen anderen Prozess gesperrt wurde.
Ursache
Diese Ausnahme wird aufgrund eines Problems der Sperre ausgelöst, dessen tatsächliche Ursache eine der folgenden sein kann:
- Ein CRX-Instanz, der die Sperre für einen gemeinsamen Ordner speichert (Version, Arbeitsbereich, Protokoll oder Repository) wurde ungewöhnlich heruntergefahren und hinterlässt statische
.lock-Dateien - Ein CRX-Clusterknot hält zurzeit die Sperre für einen freigegebenen Ordner, aber andere CRX-Clusterinstanzen können keine Verbindung zum CRX-Master-Clusterknoten herstellen.
Die erste Situation ist normalerweise nicht problematisch. Die statische .lock-Datei wird entfernt und ersetzt. Bei Verwendung einer älteren Version von NFS kann das Dateisystem nach einem Absturz die Dateisperre dieser Datei jedoch nicht freigeben.
Letzteres ist allerdings ein Problem, da Kommunikation zwischen einem Slave- und einem Master-CRX-Knotenpunkt erforderlich ist, um eine ordnungsgemäße Synchronisierung des Schreibzugriffs auf das Repository sicherzustellen. Wenn ein Slave-Clusterknoten über das Netzwerk keine Verbindung mit dem Master-Clusterknoten herstellen kann, geht er davon aus, dass dieser nicht ausgeführt wird und versucht, die Masterrolle zu übernehmen.
Lösung
Wenn Sie eine ältere Version von NFS verwenden, stellen Sie sicher, dass alle Prozesse beendet sind und löschen Sie alle .lock-Dateien manuell. Wenn das Problem hierdurch nicht behoben werden kann, überprüfen Sie den "address"-Parameter der listener.properties-Datei innerhalb des freigegebenen Ordners, der das Problem verursacht.
Beispiel:
address=192.168.1.22\:58128
Diese Datei wird von allen (Slave-)CRX-Clusterknoten gelesen. Die IP-Adresse muss daher von allen Slave-Maschinen erreichbar sein, andernfalls tritt besagte Ausnahme auf.
Gemäß der Standardeinstellung verwendet CRX eine beliebige verfügbare Netzwerkschnittstelle und einen beliebigen verfügbaren Port. Es ist auch möglich, eine IP-Adresse und einen Portbereich explizit für die Verwendung zuzuweisen. Diese Einstellungen müssen auf der TarPersistenceManager-Ebene festgelegt werden, sowohl unter repository.xml als auch unter 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>
Gilt für
CRX1.4.x (mit Cluster).
Bei Ihrem Konto anmelden