Guest

Cisco Unified Contact Center Express

IPCC: Troubleshoot Mutex Lock Errors

Document ID: 91203



Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Problem
Solution 1 - For the DC Directory Environment
Solution 2 - For the Active Directory Environment
Error: Cannot acquire ClusterMutex
Solution
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

In a Cisco Unified Contact Center Express environment, a user cannot change configurations in the trigger information section of the Java Telephony Application Programming Interface (JTAPI) Triggers on the Cisco Customer Response Solution (CRS) Admin. In the attempt to change the application in the trigger information section of the JTAPI Triggers, this error message appears in the MADM log:

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 

This document describes how to troubleshoot these mutex lock errors.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • Cisco CRS

  • DC Directory Administration

  • Active Directory

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Problem

When a user attempts to update the JTAPI Triggers using the Cisco CRS Application Admin, this error message appears:

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 

This is a known defect when a lock entry is missing in the Lightweight Directory Access Protocol (LDAP). This issue is documented by Cisco bug ID CSCsd13553 ( registered customers only) .

Solution 1 - For the DC Directory Environment

If this is a DC Directory environment, use this solution to solve the problem.

Note: You need to log into the DC Directory Manager as a Directory Manager in order to make the necessary changes.

  1. In the DC Directory LDAP, choose CCN Apps > clusters > [profile] > Locks > Locks.00000000 and confirm that these mutex lock entries are named as this list shows:

    lockApplicant?empty
    lockOwner?empty
    lockUsage?empty,
    lockUserInfo?empty
    lockUserTimestamp?empty
  2. If any of the entries in step 1 are missing the ?empty suffix in their name, then they need to be renamed to exactly match the list in step 1.

    Note: You can ignore the lockExpiration entry. It does not need the ?empty suffix in the name.

  3. If any of the lock____?empty entries are missing completely, you must add them manually. In order to add the entry, complete these steps:

    Note: The lockApplicant?empty value is used for illustration purposes only.

    1. Right-click on Locks.00000000 and select New > ciscoCCNocConfigInfoCES.

    2. Enter the name as lockApplicant?empty and press Enter.

    3. In the next window, click Add and enter x in the Enter String value box. Then click OK.

    4. Click OK again.

  4. Once you have confirmed that all of these entries are named properly, confirm that these entries have the value configured as x (lowercase x):

    lockApplicant?empty
    lockOwner?empty
    lockUsage?empty,
    lockUserInfo?empty
    lockUserTimestamp?empty

    Note: Ignore the lockExpiration entry in this step. Its value should not be x.

    If any of these lock entry values is not configured as x, then configure them as x.

Solution 2 - For the Active Directory Environment

If you have an Active Directory (AD) integration, you need to use ADSI Edit leavingcisco.com in order to change the lock parameters. Complete these steps in order to resolve the issue in an AD environment:

  1. On the AD server, you can browse your directory schema when you open the Active Directory Services Interface (ADSI) edit utility. Then drill down to dc=xxxxx, dc=com, ou=Cisco, ou=CCNApps, ou=clusters, ou= <profilename>, ou=Locks, ou=Locks.000000000.

  2. Check that the lock entries are named as this list shows:

    lockApplicant?empty
    lockOwner?empty
    lockUsage?empty,
    lockUserInfo?empty
    lockUserTimestamp?empty
  3. If any of the entries in step 2 are missing the ?empty suffix in their name, then they need to be renamed to exactly match the list in step 2.

  4. If any of the lock____?empty entries are missing completely, then you need to add them manually. Complete these steps in order to add the entry:

    Note: The lockApplicant?empty value is used for illustration purposes only.

    1. Right-click on Locks.00000000 and select New > Object > ciscoCCNocConfigInfoCES.

    2. Enter the name as lockApplicant?empty and press Next.

    3. In the next window, click More Attributes.

    4. From the Select a Property to View pull-down menu, select ciscoCCNatConfigInfoCESValue.

    5. In the Edit Attribute: box, enter x and click Add.

    6. Click OK.

    7. Click Finish.

  5. Once you have confirmed that all entries are named properly, confirm that these entries have the value configured as x (lowercase x):

    lockApplicant?empty
    lockOwner?empty
    lockUsage?empty,
    lockUserInfo?empty
    lockUserTimestamp?empty

    Note: Ignore the lockExpiration entry in this step. Its value should not be x.

    If any of these lock entry values are not configured as x, then complete these steps in order to configure them as x:

    1. Right-click on lockApplicant?empty and choose Properties.

      Note: The lockApplicant?empty value is used for illustration purposes only.

    2. From the Attributes: box, select ciscoCCNatConfigInfoCESValue and click Edit.

    3. Highlight the existing entry in the Values: box and click Remove (skip if none are present).

    4. In the Value to add: box, type x and click Add. Then click OK.

    5. Click Apply and then OK.

Error: Cannot acquire ClusterMutex

When the user sets up call wrap up time for the agents in the Customer Response Solutions Administration application, this error message appears:

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.]

Solution

Complete these steps in order to resolve this issue:

  1. Go to the C:\program files\wfavvid\ClusterData\Default\ folder on the CRS server.

  2. Rename the com.cisco.crs.cluster.config.LockConfig folder to com.cisco.crs.cluster.config.LockConfig.bak.

  3. Restart Node Manager.

If you do not wish to restart Node Manager, here is another way of clearing MutexLocks:

  1. Click Start and type CET.

  2. Choose No on popup message.

  3. Find and click com.cisco.crs.cluster.config.LockConfig in the list located on the left.

  4. Double-click the one record located on the right.

  5. Select the com.cisco.crs.cluster.config.LockConfig tab located at the top.

  6. Clear any fields that are not empty.

NetPro Discussion Forums - Featured Conversations

Networking Professionals Connection is a forum for networking professionals to share questions, suggestions, and information about networking solutions, products, and technologies. The featured links are some of the most recent conversations available in this technology.
NetPro Discussion Forums - Featured Conversations for Customer Contact Software
IP Communications and Video: Contact Center

Related Information



Updated: Apr 18, 2007Document ID: 91203