When the number of client UAPs to be connected to a single scheduler daemon increases, you may not be able to specify a sufficient number of socket descriptors to be used by the scheduler daemon. If there are insufficient socket descriptors for the scheduler daemon, the system requests disconnection and then ends a connection in order to reserve new socket descriptors. Depending on the load exerted on the system by this disconnection processing, the scheduling performance of the scheduler daemon may drop.

The figure below shows an example of a system that has insufficient socket descriptors.

Figure C-3 Example of a system that has insufficient socket descriptors

OpenTP1 uses TCP/IP as its communication protocol. Therefore, a connection establishment request (connect system call) from a client UAP is held in a wait queue of the listen system call until it is fetched by the accept system call.

The number of connection establishment requests that can be held in the wait queue depends on the operating system. However, if client UAPs send numerous requests at one time, the number of generated connection establishment requests may exceed the number of requests that can be held in the queue.

If client UAPs generate more connection establishment requests than can be held in the wait queue, CUP (TP1/Client) outputs the message KFCA02449-E, and SUP and SPP (TP1/Server Base) output the message KFCA00327-W. The system may consider that the service requests failed due to a communication error or because OpenTP1 was not started.

The figure below shows an example of a system in which the connect system call encountered an error.

Figure C-4 Example of a system in which the connect system call encountered an error

While the receive thread of the scheduler daemon is receiving a service request message from a particular client UAP, it cannot receive a service request message from another client UAP. (However, if a service request message exceeds 32 kilobytes, it is split before being sent.)

Therefore, processing for receiving a message from a client UAP connected to a network that has a low line speed delays processing for receiving a message from a client UAP connected to a network that has a high line speed. The performance of the network that has a high line speed may thus be compromised.

The figure below shows an example of a system that uses networks with different line speeds. This example compares the two lines having different speeds. A comparison of lines where one line is twice as fast as the other line shows that receive processing for the slow line takes twice as long as that for the fast line. This difference in the processing time corresponds exactly to the difference in the line speed.

Figure C-5 Example of a system using networks that have different line speeds

Assume that processing for sending a service request message to the scheduler daemon is interrupted because, for instance, the client UAP was forcibly terminated. In this case, scheduling may be delayed until message receive processing by the receive thread reaches a time-out.

The figure below shows an example of a system in which service request messages are interrupted.

Figure C-6 Example of a system in which service request messages are interrupted

If the scheduler daemon receives a very large number of service request messages at one time from client UAPs and does not have the capacity to process them, there may be a temporary deficiency of processing threads.

If a deficiency of processing threads occurs, the system outputs the message KFCA00356-W and may temporarily consider that the service requests failed due to a communication error or time-out.

Specify the timing for outputting the message KFCA00356-W in rpc_server_busy_count in the system common definition. For details, see the manual OpenTP1 System Definition.

The figure below shows an example of a system in which the processing threads are temporarily deficient.

Figure C-7 Example of a system in which the processing threads are temporarily deficient