Troubleshooting deployment issues

To diagnose server problems, enable the DEBUG log level. If necessary, enable the ALL log level to turn on all logging.

For information about troubleshooting WebSphere Application Server deployments, see Troubleshooting deployment issues in the deployment documentation for the 8.9 release.

Problem: Silent single sign-on (SSO) does not work

Look for Native library INFO message, which can indicate an authentication library loading error.

If there are no library loading issues and the log file shows authentication handshake sequences, then an issue may occur with the account setup. Check the service principal registration with setspn -L, as well as the following:

The container service accounts
The user groups of the accounts that try to log in ("nexjuser")
Proper Kerberos principals as User.login values in the database

For more information, on configuring SSO, see Configuring single sign-on.

Problem: Silent single sign-on does not work for certain users on certain machines

Ensure that you have configured silent Single Sign-On (SSO) for all users.

For more information on configuring silent SSO, see Configuring user browsers for silent single sign-on.

Problem: Server cannot start due to nexjsa login failure

The system probably cannot find the system user.

Check if a Kerberos principal is needed for Single Sign-On or has been left in the database.

Problem: Server cannot start due to a port conflict

Make sure that the TCP ports have been configured properly in the registry, as described in the development environment setup guide.

Check if another instance of Tomcat is running and stop any Outlook and MSN IM client instances.

Problem: Cluster cannot receive application requests

Try the following actions:

Check the log files for correct joining of cluster members.
Verify the firewall settings.
Verify that the time is automatically synchronized within <1 sec between the nodes.
Make sure that the redirector is configured correctly, including its virtual directory authentication settings.
Enable the redirector debug log level. Use a network sniffer (e.g. Wireshark) to identify communication issues.

Problem: Random connectivity errors

Disable any superfluous network interfaces.

This problem is common on development laptops with simultaneous active wireless and LAN connections.

Problem: Oracle error "ORA-01000: maximum open cursors exceeded"

Check if the maximum cursor limit in the database is at least (RelationalDatabaseConnection.statementCacheSize + 10):

To check the value, run the following:

CODE

select value from v$parameter where name='open_cursors';

If not, set it as follows (assuming that statementCacheSize=1000):

CODE

alter system set open_cursors=1010 scope=both;

Problem: Errors related to encryption key size

Make sure that the NexJ Studio JRE and the application server JRE have matching encryption policy files.

Problem: Invalid certificate error: javax.net.ssl.SSLHandshakeException

If you receive this error: "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)", perform the following steps:

Log on to OWA using http://<host>/exchange/<user>.
An invalid certificate message will be shown.
Click on the Invalid Certificate button and press View Certificate.
Go to the Details tab.
Select Copy to File at the bottom. The Export wizard will appear.
Select the first option, DER -encoded binary.
Save to C:\.
Import the certificate that was saved in step 7 into the JRE certificate keystore in %JAVA_HOME%\jre\lib\security\cacerts. Debug the certificate handling by specifying the system property javax.net.debug=true in the server Process Definition/JVM Custom Properties.

Verify the import was successful by running the following command:

CODE

keytool -list -alias <server_name> -keystore <dir>\cacerts -storepass changeit

Restart the application server.

Problem: Errors related to busy or unavailable data sources

Increase the database connection pool size limit or improve the performance of long-running queries.

Errors might occur if the maximum connection pool size is too small or if queries take too long to process.

If you receive the error "Data source "<DataSourceName>" is temporarily unavailable. (err.persistence.unavailable)" or "Unable to allocate a resource in <QueryTimeout> ms due to reaching the maximum pool size of <MaxPoolSize>. (err.pool.resource.busy)", you can take the following steps to help prevent the error from occurring in the future:

Optimize long-running queries.
Increase the maximum database connection pool size. To do this:

In NexJ Studio, open the environment file for your deployment.
In the Data Source Connections tab, select Relational Database Connections, and click the Advanced subtab.
In the Max Pool Size field, enter a greater value for the maximum number of available database connections.

Increase the maximum database connection pool size to the value given by the following calculation:
CODE
```
(<Average Active Connection Count> / 60) * (<Average Processing Time> / 1000) * 1.1
```

To find the Average Active Connection Count and Average Processing Time values:

In NexJ System Admin Console, navigate to the Statistics page.
In the list in the Statistics area, expand the tree node for your NexJ application. For example, nexj.finance.
Expand the node for the server whose maximum database connection pool size you want to increase. For example, node1.
Expand the DataSource node.
Expand the RelationalDatabase node.
Expand the node for the database whose maximum connection pool size you want to increase. For example, DefaultRelationDatabase.
Select the [default] node. The statistics for the node are displayed in the right pane.

Info

If you are running your application on a server cluster, you should perform the calculation for all nodes in the cluster, then use the average or maximum value as your connection pool size limit. The setting for the maximum database connection pool size in the environment file applies to all nodes in a cluster.