In einer Cisco Unified Contact Center Express-Umgebung kann ein Benutzer die Konfigurationen im Triggerabschnitt "Trigger Information" der Java Telefony Application Programming Interface (JTAPI)-Trigger für den Cisco Customer Response Solution (CRS) Admin nicht ändern. Beim Versuch, die Anwendung im Trigger-Informationsabschnitt der JTAPI-Trigger zu ändern, wird diese Fehlermeldung im MADM-Protokoll angezeigt:
java.lang.InterruptedException: User (CRSuser) attempt to acquire mutex lock for the purpose of (Cluster Mutex acquired by JTAPI Provider - Update.), but could not acquirelock within (3000) milisecond. Please try after few minutes
In diesem Dokument wird beschrieben, wie diese Mutex-Sperrfehler behoben werden.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Cisco CRS
Cisco Unified Contact Center Express
DC-Verzeichnisverwaltung
Active Directory
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).
Wenn ein Benutzer versucht, die JTAPI-Trigger/Upload-Aufforderungen oder -Skripts mithilfe des Cisco CRS Application Admin zu aktualisieren, wird folgende Fehlermeldung angezeigt:
java.lang.InterruptedException: User (CRSuser) attempt to acquire mutex lock for the purpose of (Cluster Mutex acquired by JTAPI Provider - Update.), but could not acquirelock within (3000) milisecond. Please try after few minutes
Dies ist ein bekannter Fehler, wenn im LDAP (Lightweight Directory Access Protocol) ein Sperreintrag fehlt. Dieses Problem wird durch die Cisco Bug ID CSCsd13553 dokumentiert (nur registrierte Kunden).
Wenn es sich um eine Rechenzentrumsumgebung handelt, können Sie dieses Problem mithilfe dieser Lösung beheben.
Hinweis: Sie müssen sich als Verzeichnismanager beim DC Directory Manager anmelden, um die erforderlichen Änderungen vorzunehmen.
Wählen Sie im Rechenzentrums-VerzeichnisLDAP die Option CCN-Apps > Cluster > [Profil] > Locks > Locks.0000000 aus, und bestätigen Sie, dass diese Mutex-Sperreinträge wie folgt benannt sind:
lockApplicant?empty lockOwner?empty lockUsage?empty, lockUserInfo?empty lockUserTimestamp?empty
Wenn bei einem der Einträge in Schritt 1 das ?leere Suffix in ihrem Namen fehlt, müssen sie umbenannt werden, damit sie genau der Liste in Schritt 1 entsprechen.
Hinweis: Sie können den Eintrag lockExpiration ignorieren. Es benötigt das ?leere Suffix im Namen nicht.
Wenn irgendwelche der lock____?leeren Einträge vollständig fehlen, müssen Sie sie manuell hinzufügen. Gehen Sie wie folgt vor, um den Eintrag hinzuzufügen:
Hinweis: Der Wert lockApplication?empty wird nur zu Illustrationszwecken verwendet.
Klicken Sie mit der rechten Maustaste auf Locks.00000000, und wählen Sie New > ciscoCCNocConfigInfoCES aus.
Geben Sie den Namen als lockApplication?empty ein, und drücken Sie die Eingabetaste.
Klicken Sie im nächsten Fenster auf Hinzufügen, und geben Sie x im Feld Zeichenfolgenwert eingeben ein. Klicken Sie anschließend auf OK.
Klicken Sie erneut auf OK.
Nachdem Sie bestätigt haben, dass alle Einträge korrekt benannt sind, vergewissern Sie sich, dass dieser Wert als x konfiguriert ist (Kleinbuchstaben x):
lockApplicant?empty lockOwner?empty lockUsage?empty, lockUserInfo?empty lockUserTimestamp?empty
Hinweis: Ignorieren Sie in diesem Schritt den Eintrag lockExpiration. Der Wert sollte nicht x sein.
Wenn einer dieser Sperreingabewerte nicht als x konfiguriert ist, konfigurieren Sie sie als x.
Wenn Sie eine Active Directory (AD)-Integration haben, müssen Sie ADSI-Bearbeitung um die Parameter der Sperre zu ändern. Gehen Sie wie folgt vor, um das Problem in einer AD-Umgebung zu beheben:
Auf dem AD-Server können Sie das Verzeichnisschema durchsuchen, wenn Sie das Bearbeitungsdienstprogramm Active Directory Services Interface (ADSI) öffnen. Machen Sie anschließend detaillierte Informationen zu dc=xxxxx, dc=com, ou=Cisco, ou=CCNApps, ou=clusters, ou= <profilename>, ou=Locks, ou=Locks.000000000.
Überprüfen Sie, ob die Sperreinträge wie folgt benannt werden:
lockApplicant?empty lockOwner?empty lockUsage?empty, lockUserInfo?empty lockUserTimestamp?empty
Wenn bei einem der Einträge in Schritt 2 das ?leere Suffix in ihrem Namen fehlt, müssen sie umbenannt werden, damit sie genau der Liste in Schritt 2 entsprechen.
Wenn irgendwelche der lock____?empty Einträge komplett fehlen, dann müssen Sie sie manuell hinzufügen. Gehen Sie wie folgt vor, um den Eintrag hinzuzufügen:
Hinweis: Der Wert lockApplication?empty wird nur zu Illustrationszwecken verwendet.
Klicken Sie mit der rechten Maustaste auf Locks.0000000 und wählen Sie New > Object > ciscoCCNocConfigInfoCES aus.
Geben Sie den Namen als lockApplication?empty ein, und drücken Sie Weiter.
Klicken Sie im nächsten Fenster auf Weitere Attribute.
Wählen Sie im Pulldown-Menü Wählen Sie eine Eigenschaft aus, die angezeigt werden soll die Option ciscoCCNatConfigInfoCESValue aus.
Im Edit-Attribut: ein, geben Sie x ein und klicken Sie auf Hinzufügen.
Klicken Sie auf OK.
Klicken Sie auf Fertig stellen.
Nachdem Sie bestätigt haben, dass alle Einträge korrekt benannt sind, vergewissern Sie sich, dass dieser Wert als x (Kleinbuchstaben x) konfiguriert ist:
lockApplicant?empty lockOwner?empty lockUsage?empty, lockUserInfo?empty lockUserTimestamp?empty
Hinweis: Ignorieren Sie in diesem Schritt den Eintrag lockExpiration. Der Wert sollte nicht x sein.
Wenn einer dieser Sperreingabewerte nicht als x konfiguriert ist, führen Sie die folgenden Schritte aus, um sie als x zu konfigurieren:
Klicken Sie mit der rechten Maustaste auf lockApplication?empty, und wählen Sie Eigenschaften aus.
Hinweis: Der Wert lockApplication?empty wird nur zu Illustrationszwecken verwendet.
Aus den Attributen: wählen Sie ciscoCCNatConfigInfoCESValue aus und klicken Sie auf Bearbeiten.
Markieren Sie den vorhandenen Eintrag in den Werten: und klicken Sie auf Entfernen (überspringen, wenn keine vorhanden sind).
Zu addierende Werte: ein, geben Sie x ein, und klicken Sie auf Hinzufügen. Klicken Sie anschließend auf OK.
Klicken Sie auf Übernehmen und dann auf OK.
Wenn der Benutzer die Abwicklungszeit für die Agenten in der Anwendung "Kundenantwort-Lösungsadministration" eingerichtet hat, wird folgende Fehlermeldung angezeigt:
Can not acquire ClusterMutex; nested exception is: com.cisco.config.ConfigException: UnmarshalException; nested exception is: javax.xml.bind.UnmarshalException: Content is not allowed in prolog. - with linked exception: [org.xml.sax.SAXParseException: Content is not allowed in prolog.]
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
Öffnen Sie den Ordner C:\program files\wfavvid\ClusterData\Default\ auf dem CRS-Server.
Benennen Sie den Ordner com.cisco.crs.cluster.config.LockConfig in com.cisco.crs.cluster.config.LockConfig.bak um.
Node Manager neu starten
Wenn Sie den Node Manager nicht neu starten möchten, gibt es eine andere Möglichkeit, MutexLocks zu löschen:
Klicken Sie auf Start, und geben Sie CET ein.
Wählen Sie No on popup message aus.
Suchen und klicken Sie in der Liste links auf com.cisco.crs.cluster.config.LockConfig.
Doppelklicken Sie auf den einen Datensatz rechts.
Wählen Sie die Registerkarte com.cisco.crs.cluster.config.LockConfig oben aus.
Löschen Sie alle Felder, die nicht leer sind.
Wenn Sie versuchen, die Fähigkeiten einer Ressource zu ändern, wird dieser Fehler ausgegeben:
Error: can not acquire ClusterMutex; nested exception is: com.cisco.config.ConfigException: Store config record – error: config request timed out.
Dieser Fehler kann durch eines der folgenden Probleme verursacht werden:
Beim Sicherungsprozess wurde die Sperre nicht von der DB gelöscht, aber die Sperren und das Archiv sind auf beiden Servern sauber.
Die Sperrkonfigurationsdatei kann ein Problem haben. Insbesondere kann der Server nicht mehr davon lesen, oder die darin enthaltene XML-Datei wurde beschädigt.
Gehen Sie wie folgt vor, um dieses Problem zu beheben:
Stellen Sie anhand des CET sicher, dass die Sperren und das Archiv auf beiden Servern sauber sind.
Überprüfen Sie die NIC-Reihenfolge, und klicken Sie auf richtig.
Öffnen Sie den Ordner C:\program files\wfavvid\ClusterData\Default\ auf dem CRS-Server.
Benennen Sie den Ordner com.cisco.crs.cluster.config.LockConfig in com.cisco.crs.cluster.config.LockConfig.bak um.
Starten Sie den Cluster neu.
Gehen Sie wie folgt vor, um die Mutex-Sperreinstellung auf der DB zu überprüfen:
Gehen Sie zu Start > Ausführen, geben Sie cet ein, und drücken Sie die Eingabetaste.
Klicken Sie beim Popup-Fenster auf Nein.
Doppelklicken Sie im linken Teilfenster auf diesen Konfigurationsobjekttyp: com.cisco.crs.cluster.config.ClusterSpecificConfig.
Doppelklicken Sie im rechten Teilfenster auf die Zeile, die für Ihren Knoten zurückgegeben wurde.
Klicken Sie im neuen Fenster auf die Registerkarte com.cisco.crs.cluster.config.ClusterSpecificConfig.
Klicken Sie auf die Registerkarte Archiv.
Wenn doppelte Kostenvoranschläge für Archiv-ID, Archivierungsanfrage-Info, Archiv-Benutzerinfo oder Archive-Client vorhanden sind, löschen Sie den Inhalt, lassen Sie den doppelten Kostenvoranschlag jedoch unverändert.
Klicken Sie auf Übernehmen.
Klicken Sie auf OK, damit die Änderungen wirksam werden.
Wählen Sie die Registerkarte com.cisco.crs.cluster.config.LockConfig oben aus.
Wenn doppelte Anführungszeichen für Besitzer sperren, Nutzung sperren oder Benutzerinformationen sperren vorhanden sind, löschen Sie den Inhalt, lassen Sie jedoch die doppelten Anführungszeichen.
Klicken Sie auf Übernehmen.
Klicken Sie auf OK, damit die Änderungen wirksam werden.
Führen Sie die gleiche Prozedur im zweiten Knoten aus, wenn Sie über zwei UCCX-Server verfügen.
Beim Versuch, die vorhandene Konfiguration zu aktualisieren, wird folgender Fehler ausgegeben:
User (lawr) attempt to acquire mutex lock for the purpose of (Cluster Mutex acquired by ICD - CSD RG Update.), but could not acquire lock within (3000) milisecond. Please try after few minutes
Wenn Sie den Node Manager neu starten und neu starten, bleibt das RMCM-Subsystem im Initialisierungszustand. Beim Versuch, die Sperre freizugeben, müssen Sie einige der Attribute löschen und neue erstellen. LDAP löst daher manchmal einen Fehler aus. Dadurch wird dieses Attribut nicht erstellt. Ab diesem Zeitpunkt führt jeder Appadmin-Vorgang zu einem ClusterMutex-Fehler, und ein Neustart des Motors bewirkt, dass RmCm im Initialisierungszustand feststeckt, da er die ClusterMutex-Sperre nicht abrufen kann.
Gehen Sie wie folgt vor, um den lockApplication-Eintrag hinzuzufügen:
Klicken Sie mit der rechten Maustaste auf die Datei Locks.xxxxxxx, und wählen Sie Neu > ciscoCCNocConfigInfoCES aus.
Geben Sie den Namen als lockApplication?empty ein, und drücken Sie die Eingabetaste.
Klicken Sie im nächsten Fenster auf Hinzufügen, und geben Sie im Feld Zeichenfolgenwert eingeben x ein.
Klicken Sie auf OK.
Dies ist in der Cisco Bug ID CSCsd13553 dokumentiert (nur registrierte Kunden).