10 Troubleshooting Contacts Server

This chapter describes troubleshooting strategies for Oracle Communications Contacts Server.

Troubleshooting Contacts Server Initial Configuration

If you experience trouble configuring Contacts Server while running the init-config initial configurator script and you receive an error from the application server, ensure that you are running the recommended Java version based on the JDK support available for the container and that your environment is configured appropriately.

Note:

If you use GlassFish Server 3.x, use the JDK version 1.7 and if you use WebLogic Server 12.x, use the JDK version 1.8. For more information, see the installation guide of the corresponding application server.

Troubleshooting Application Server and Java

If you upgrade your Java SE to Java SE Development Kit 7, Update 7 (JDK 7u7) or later, you must also upgrade GlassFish Server to the recommended patch level. If you use WebLogic Server, upgrade Java to the recommended JDK8 update version as suggested by the WebLogic Server version. Otherwise, you may encounter problems running the davadmin command.

Troubleshooting Tips

Begin troubleshooting by ensuring that the application server web container is running and that Contacts Server is deployed. You can use either the application server's Administration Console or the command-line utilities.

Topics in this section:

Using the asadmin Command to Specify GlassFish Server Port

If you have more than one GlassFish Server instance installed, use the asadmin -p command to specify the instance's administrative port number.

Using GlassFish Server to Check Contacts Server Status

You can use either the GlassFish Server Administration Console or the asadmin command to check Contacts Server status.

To use the Administration Console to check status:

  1. Start the GlassFish Server Administration Console.

  2. Navigate to Web Applications under the Applications tab.

  3. Ensure that the nabserver process is deployed and enabled.

To use the asadmin command to check status:

  1. Log in to the GlassFish Server host as root.

  2. Change to the GlassFish_home/bin directory.

  3. Run the following commands:

    asadmin list-components -p admin-port
    nabserver <ejb,web>
    Command list-components executed successfully.
    asadmin show-component-status -p admin-port nabserver
    Status of nabserver is enabled.
    Command show-component-status executed successfully.
    

If the nabserver is not enabled, check the log files specified in "Troubleshooting Contacts Server nabserver Process".

Using the WebLogic Server Administration Console to Check Contacts Server Status

To check the Contacts Server status by using the WebLogic Server Administration console:

  1. Start the WebLogic Server Administration Console.

  2. In the Domain Structure section, click the domain name. For example, domain1.

  3. Navigate to Environment, Servers, and then to the Configuration tab.

    Note:

    Ensure that the Administration Server and Managed Server in which Contacts Server is deployed are up and running.
  4. Navigate to Deployments.

  5. Ensure that nabserver is deployed under the Configuration tab.

Troubleshooting Contacts Server nabserver Process

To troubleshoot when Contacts Server is not starting or not allowing clients to connect:

  1. If the nabserver process is not enabled, check the application server log in which Contacts Server is deployed.

    • On GlassFish Server:

      Check server.log in the GlassFish_home/domains/domain1/logs directory.

    • On WebLogic Server:

      Check managed_server_name.log in Weblogic_Domain/servers/managed_server_name/logs directory.

  2. If the nabserver process is deployed and enabled but Contacts Server clients have trouble connecting, check the Contacts Server log, error.*, in the /var/opt/sun/comms/nabserver/logs directory. To increase the Contacts Server log level to collect more information to help to troubleshoot the problem, run the following command:

    davadmin config -o log.dav.errors.loglevel -v FINEST
    

Troubleshooting a Failing davadmin Command

For GlassFish Server:

If a davadmin command fails to run, use the -e option to get more details about the failure. For example:

davadmin version
Enter Admin password:*********
DAV server connection failed. Is the server running?

davadmin version -e
Enter Admin password:*********
JMXconnection exception for url
service:jmx:rmi:///jndi/rmi://commsuite.example.com:46633/jmxrmi
- Exception creating connection to: 1.1.1.1; nested exception is:
java.net.SocketException: java.security.NoSuchAlgorithmException: Error
constructing implementation (algorithm: Default, provider: SunJSSE, class:
com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl)

This example shows SSL errors. In this case, ensure that the truststore file is valid. The default truststore file, .asadmintruststore, is located in the Contacts Server config directory.

To verify that the truststore file is valid:

  1. Log in to the GlassFish Server host as root where Contacts Server is deployed.

  2. Run an asadmin command.

    GlassFish Server creates a new .asadmintrustore file located under the root (/) directory.

  3. Ensure that this file is the same as the one in the Contacts Server config directory.

See also "Troubleshooting Application Server and Java".

For WebLogic Server:

If you use WebLogic Server and when davadmin command is successful, the following output is displayed:

/opt/sun/comms/nabserver/sbin/davadmin version
Enter Admin password: *********
Handshake succeeded: TLSv1.2
Oracle Communications Contacts Server version: 8.0.0.5.0 (built yyyy-mm-dd-Time)

The following example shows the output when the davdmin command fails:

/opt/sun/comms/nabserver/sbin/davadmin version 
Enter Admin password: *********
Handshake failed: TLSv1.2, error = sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Handshake failed: TLSv1.1, error = sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Handshake failed: TLSv1, error = Received fatal alert: handshake_failure
Handshake failed: TLSv1.2, error = sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Handshake failed: TLSv1.1, error = sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Handshake failed: TLSv1, error = Received fatal alert: handshake_failure
Server unavailable at url: service:jmx:t3s://commsuite.example.com:46633/jndi/weblogic.management.mbeanservers.runtime

In the example, 46633 is the secure port of the managed server in which Contacts Server is deployed.

This example shows SSL errors. In this case, check the following to troubleshoot the issue:

  • WebLogic Server is configured in Secure mode using the supported keystores

  • WebLogic Administration Console is accessible as https://hostname:secure_port/console

  • The extractSSLArgs.sh script runs successfully in a secure mode before doing initial configuration.

    sh ./extractSSLArgs.sh -u weblogic_admin_user -p weblogic_admin_user_password -l t3s://weblogic_server_host:SSL_port
    
  • If there is a problem in running the above script successfully, try to use WLST command to connect to the server.

    wls:/offline> connect(weblogic_admin_user,weblogic_admin_user_password,t3s://weblogic_server_host:SSL_port");
    
  • WebLogic_Domain/config contains a valid .wls_sslargs file and the contents correspond to the same keystore options that is configured at the WebLogic Server Side Secure Configuration.

  • davadmin.properties file under ContactsServer_home/config folder contains proper details.

    For example:

    port=managed_server_port

    secure=location of truststore used in configuring WebLogic Server in secure mode

    For more information, see the discussion about running extractSSLArgs.sh to validate and store WebLogic Server SSL details in the Contacts Server Installation and Configuration Guide.

Troubleshooting Back-end Database Errors

If you find a back-end error, do one of the following to ensure that the database is running by pinging the JDBC connectionpool.

If you use GlassFish Server:

  1. Start the GlassFish Server Administration Console.

  2. Select JDBC Resources from Resources, then select Connection Pools.

  3. Choose the nabPool and perform a ping.

    Note:

    If the ping fails, check the Pool properties to ensure they are correct.
  4. You can also perform a command-line ping as follows:

    asadmin list-jdbc-connection-pools -p admin-port
    __CallFlowPool
    __TimerPool
    DerbyPool
    nabPool
    Command list-jdbc-connection-pools executed successfully.
    
    asadmin ping-connection-pool -p admin-port nabPool
    Command ping-connection-pool executed successfully.
    
  5. Even if you ping the pool, sometimes Contacts Server is not able to load the back end. In this case, you see errors similar to the following:

    SEVERE  [2009-09-03T22:00:53.310-0700] <...JdbcBackend.getDataSource> Cannot lookup DataSource: javax.naming.NameNotFoundException: defaultbackend1 not found
    
    SEVERE  [2009-09-03T22:00:53.313-0700] <...nabserver.loadBackend> failed to instantiate or create backend com.sun.comms.nabserver.backends.BackendException: Cannot get DataSource: javax.naming.NameNotFoundException: defaultbackend1 not found(OPERATION_NOT_SUPPORTED)
    
  6. To see the pool and resource data clearly, view the GlassFish Server configuration file:

    GlassFish_home/domains/domain1/config/domain.xml
    
  7. If the cause of the error is not clear, delete and recreate the connection pool and JDBC resource by using the asadmin command. If you recreate the JBDC resource, be sure to use the same user name and password that you initially used to create the resource.

    • MySQL Server:

      asadmin delete-jdbc-connection-pool -p admin-port nabPool
      asadmin create-jdbc-connection-pool -p admin-port --user admin --datasourceclassname com.mysql.jdbc.jdbc2.optional.MysqlDataSource --restype javax.sql.DataSource --property "DatabaseName=nab:serverName=mysqlhost:user=nab:password=mysqlpass:portNumber=3306:networkProtocol=jdbc" nabPool
      asadmin create-jdbc-resource -p admin-port --user admin --connectionpoolid nabPool jdbc/defaultbackend
      
    • Oracle Database:

      asadmin delete-jdbc-connection-pool -p admin-port nabPool
      asadmin create-jdbc-connection-pool --user admin --port admin-port --restype javax.sql.DataSource --datasourceclassname oracle.jdbc.pool.OracleDataSource --isconnectvalidatereq=true --validationmethod table --validationtable DUAL --property \"url=jdbc\\\:oracle\\\\:thin\\\:@//${dbhost}\\\:${dbport}/${sid}:user=${nabuser}:password=${nabuserpw}\" nabPool
      asadmin create-jdbc-resource -p admin-port --user admin --connectionpoolid nabPool jdbc/defaultbackend
      
  8. Restart GlassFish Server after recreating the connectionpool and resource.

If you use WebLogic Server:

  1. Start the WebLogic Server Administration Console.

  2. In the left pane of the Console, under Domain Structure, select the domain name.

  3. Click Services and Data Sources.

    JDBC DataSources - defaultbackend is displayed in the Configuration tab.

  4. Select the defaultbackend JDBC Data Source name from the list.

  5. Select Configuration and General tab.

    The settings for defaultbackend are displayed.

  6. Navigate to the Connection Pool tab and ensure that the properties are correct.

  7. Navigate to Monitoring, and then click the Testing tab.

  8. Select the listed managed server name and click the Test Data Source button.

    Success or Error message displays in the Administration Console.

    Note:

    If the connection fails, verify the Pool properties from the Connection Pool tab to ensure all properties are correct.

    Occasionally, Contacts Server may not load the backend even though the connection to pool succeeds. To see the pool and resource data clearly, view the WebLogic Server configuration file. For example, Weblogic_Domain/config/config.xml

  9. Delete and recreate the Connection Pool and JDBC resource from WebLogic Server Administration Console if the cause of the error is unclear.

    1. Click Lock & Edit before making changes to the configuration.

    2. Click Activate Changes after making the changes and saving the configuration.

      Note:

      If you recreate the JDBC resource, ensure to use the same user name and password that you initially used to create the resource.

      If you use WebLogic Server as a container, for creating the JDBC resource, see the discussion about installing and configuring multiple Contacts Server back-end hosts for WebLogic Server manually in the Contacts Server Installation and Configuration Guide.

    3. Restart WebLogic Server after recreating the connection pool and resource.

  10. Verify the MySQL logs for any errors.

Refreshing Domain Information

Contacts Server fetches and caches some domain information that is stored in the LDAP directory, such as domain status. The system does not periodically refresh domain information, unlike user and group information.

If you need to refresh domain information, use one of the following methods:

  • Restart the application server.

  • Using the davadmin command, make a change to any of the LDAP-related configuration options (base.ldapinfo.*), which causes the server to refresh all cached LDAP data.

  • Use the davadmin cache clear command to clear the acl, domainmap, auth, and uri caches.

Tuning Directory Server

When your Oracle Directory Server Enterprise Edition contains many tens of thousands of entries, it might become necessary to tune how the directory performs searches. For example, you might experience search time outs or failures from Contacts Server. For more information, see the topic on configuring search limit in Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.

Enabling Telemetry Logging

To troubleshoot issues with a particular user or client, it is useful to log all protocol interactions. You can force all telemetry logs by setting the service.dav.telemetry.forcetelemetry parameter to true. Do not use this setting unless required as it generates lots of data.

To set the service.dav.telemetry.forcetelemetry parameter to true:

davadmin config modify -o service.dav.telemetry.forcetelemetry -v true

To enable telemetry logging at a reduced level, set the service.dav.telemetry.filter parameter. This parameter takes a space-separated list of request URI prefixes that should be logged. For example:

  • /rest/ logs all RESTful API access.

  • /dav/principals/nabuser1/ /dav/home/nabuser1/ logs all Contacts Server access to nabuser1's account (both principals and home collections, and all the resources underneath).

To set the service.dav.telemetry.filter parameter:

davadmin config modify -o service.dav.telemetry.filter -v URIs

Using the Browser Servlet in GlassFish Server Deployments

You can use a browser servlet to view address books and contacts information from a browser. You might find this helpful when troubleshooting Contacts Server problems.

To access this browser servlet, take any valid nab URI and replace the dav prefix following nabserver with browse. For example, in a browser, change the following:

http://example.com:3080/nabserver/dav/principals/smithj/addressbook/

to:

http://example.com:3080/nabserver/browse/home/smithj/addressbook/

The servlet returns a a view of the address book's properties. You can navigate among properties and delete them as well. The servlet also has some import function if you want to use a server-side import instead of a client-side import.

The delete and file import features are enabled only when the logging level is set at FINE or lower. To specify the logging level, use the log.dav.errors.loglevel configuration parameter.

Tip:

You can log in with Contacts Server administrator credentials (the default is nabmaster) to view multiple accounts with one login. Also, when viewing multiple accounts, clear your browser cache before viewing the next account.