PingAuthorize

The server is unresponsive

If the server process is running and appears to be accepting connections, but isn’t responding to requests, first use the bin/server-state command to check the current server state.

If the problem appears to be with the server software or the JVM in which it’s running, work with your authorized support provider to diagnose the problem and decide the best way to correct it.

Potential reasons for an unresponsive server include:

Busy worker threads

If all worker threads are busy processing other client requests, new requests must wait in the work queue until a thread becomes available.

  • How to diagnose: Stack traces obtained using the jstack command show that all worker threads are busy and none are waiting for new requests to process.

    If all worker threads are tied up processing the same operation for a long time, the server will also issue an alert that it might be deadlocked, which might not actually be the case. All threads might be tied up processing unindexed searches.

  • Recommendation: Use a dedicated thread pool to process administrative operations. This allows for problem diagnosis and corrective action even if all other worker threads are busy processing operations. To request that operations use the administrative thread pool, using the ldapsearch command for example, include the --useAdministrativeSession option. The requester must have the use-admin-session privilege (included for root users). By default, eight threads are available for this purpose. You can change this value with the num-administrative-session-worker-threads property in the work queue configuration.

Busy request handler

If a request handler is stuck performing expensive processing for a client connection, other requests sent to the server on connections associated with that handler must wait until the request handler is able to read data on those connections. Typically, only some client connections can experience this behavior. However, if there’s only one request handler, the problem affects all connections.

  • How to diagnose: Stack traces obtained using the jstack command show that a request handler thread is continuously blocked rather than waiting for new requests to arrive.

Improper JVM configuration

If the JVM in which the server is running isn’t properly configured, it can be forced to spend a significant amount of time performing garbage collection. In severe cases, there might be significant interruptions to Java code execution.

  • How to diagnose: Stack traces obtained from a pstack of the native process show that most threads are idle, but at least one thread performing garbage collection is active. It’s also likely that one or a small number of CPUs are 100% busy while all other CPUs are mostly idle.

    The server will issue an alert after detecting a long JVM pause because of garbage collection. This alert includes details about the pause.

Hung JVM

If the JVM in which the server is running becomes hung, the system CPUs should be mostly idle.

  • How to diagnose: The pstack utility shows that one or more threads are blocked and unable to make progress.

Network or firewall issue

If a network or firewall configuration problem arises, the server can’t receive attempts to communicate with it.

If the system becomes hung or loses power without a graceful shutdown, the behavior is often similar to that of a network or firewall configuration problem.

  • How to diagnose: A network sniffer like snoop or tcpdump shows that packets sent to the system on which the server is running aren’t receiving TCP acknowledgement.