SYMPTOMS
Entries such as the following line appearing in a FairCom DB status log file CTSTATUS.FCS:
- User# <taskid> ctntio: read error – O<taskid> bytes=0 pErr=127
|<userid>|<nodename>|: 161
- User# <taskid> ctntio: send error – O<taskid> bytes=0 pErr=128
|<userid>|<nodename>|: 161
where:
CAUSE
When a communication error occurs, the FairCom DB logs a ctntio error message in the status log file CTSTATUS.FCS. The most common cause of the “ctntio: read error” message is that a client process terminated without first disconnecting from FairCom DB. A “ctntio: send error” message can occur if the client process terminates while FairCom DB is attempting to send a response to the client process.
One common way that a client process terminates without first disconnecting from FairCom DB is that a user turns off his machine without first properly logging out of the application.
The following are other possible causes of ctntio errors in CTSTATUS.FCS:
RESOLUTION
When investigating the cause of ctntio errors, first check for the most common cause: a client process terminated without properly disconnecting from FairCom DB. Note that the application can set the node name after connecting to FairCom DB by calling the SetNodeName() FairCom DB API function. Setting a descriptive node name (including details such as process ID, thread ID and client machine name or IP address) can help you associate ctntio error messages with the corresponding client process.
If you rule out the most common explanation, check if the client application is also getting errors such as ARQS_ERR (127), could not send request) or ARSP_ERR (128), could not receive answer) when calling FairCom DB functions. In that case, check for possible network problems as follows:
Ensure FairCom DB's host machine is not burdened beyond its capacity. Using a more powerful machine or limiting the number and types of applications on a machine can improve performance and limit errors at the communication level. Also, ensure no specific application is over-using resources on the host machine.
If you find that the ctntio errors are due to heavy network activity, increasing the priority of a FairCom DB process can eliminate or reduce the occurrence of ctntio errors. This should be done cautiously as it will affect other applications running on the same machine.
The error messages in the status log can be turned off, but unless they are an inconvenience, this is not recommended. The messages serve as a good health check on the state of your network and may be an early warning of more serious network and system problems. To disable the messages, add CTSTATUS_MASK VDP_ERROR to the ctsrvr.cfg configuration file and restart FairCom DB.
MORE INFORMATION
To provide a little more context, the following a short high level description of how FairCom DB's client/server communication operates.
FairCom DB communication is initiated by the client process: the client makes the connection, the client sends the request, and the client normally terminates the connection. FairCom DB is only a "listener and responder".
In a FairCom DB process, there is a thread for each client attached to FairCom DB which is waiting on a blocking read until the next request from the client. Effectively it waits forever.
If the operating system determines that the communication channel is invalid for whatever reason (crashed client, broken network connection, overloaded network layer that cannot handle messages in a timely manner), the blocking read is released. When the blocking reads returns, the server attempts to read data from the communication channel but there is none. Based on the error code returned by the socket read operation, the thread can determine if it should retry the read. If retry is not an option or the maximum number of retries has been reached, the ctntio read error message is written to the status log file CTSTATUS.FCS and the client session is marked for termination and cleanup. This is not a fatal error to FairCom DB since it is able to abort any open transactions for the user and data integrity is assured. The effect should be more apparent on the client side because it can make no further requests to FairCom DB unless it reconnects.
