A FairCom DB client can be in a non-responsive state if a server request hangs or takes a long time to complete. As discussed above, some c tree calls (such as rebuild calls or file close calls that involve physically closing a file) may take awhile to complete. Calls to read a record with a blocking lock will hang until the lock can be acquired.
If requests made by one or more clients do not complete in a reasonable timeframe, follow these steps to identify the cause and to correct the problem:
The ctadmn utility can be used to view the current state of the client connections, including the function name for the current request being processed on behalf of each client and the current request time.
FairCom DB’s snapshot and lock dump capabilities can be used to collect details about the state of FairCom DB. For example, if ctadmn shows one or more clients hanging on record read operations, use the FairCom DB API function LockDump() to dump the current state of the server’s lock table to disk, and examine this log to determine if the read requests are simply blocking waiting to acquire a record lock. If this is the case, identify from the log which client currently holds the lock and use ctadmn to view the activity of that client or to terminate that client if appropriate.
If the cause of the long request time cannot be determined using FairCom DB utilities or FairCom DB API functions, use system utilities to monitor the server’s system calls and to collect details about the server process state. Saving a core image and stack traces for the server threads in this type of situation can help identify the cause of the hanging client requests so that the problem can be resolved.
If necessary, use ctadmn to terminate client connections that are non-responsive. If after terminating the client connections using ctadmn, the client connections still appear in the list of connected clients, FairCom DB may have to be shut down and restarted to clear the hung connections.
