5.6.1 Communication timeout when sending and receiving a request

(a) Communication timeout that can be set and detectable failures

You can set the timeout to the following two time-periods when a request is sent by the redirector:

• The time to establish a connection for sending request to the Web container

• The time to send a request to the Web container

You can detect the occurrence of failure in the Web container or on the network using the communication timeout that was set up. You can detect the following failures:

Detectable failures

• The host on which the Web container is running is down.

• A network failure occurs between the redirector and the Web container.

(b) Retrying sending of requests

If a request cannot be sent temporarily from the redirector, you can retry sending the request. A request might not be sent temporarily in the following cases:

• In the case of temporary failure of the network

• When requests are centralized in the Web container during establishment of a connection, and a request for establishing connection overflows temporarily from the listen queue

• When a Web container is yet to start completely

You can retry establishing a connection, and sending request headers. The following figure shows the flow of retry process.

Figure 5‒17: Flow of retry process when requests are sent to the Web container

Retry is executed when a timeout occurs in A or B of the figure. Retry is not executed when processing fails at C or D of the figure, and timeout occurs. The connection is closed and an error is returned to the client. Note that the failure of processing at C or D in the figure indicates failure in receiving request body from the Web server, or failure in sending request body to the Web container.

Tip

In the case of C or D in the figure, the processing of the request may have started already in the Web container. If you execute retry in the case of failure in receiving the request body from the Web server, or in the case of failure in sending the request body to the Web container, the send process may be duplicated, and therefore, retry is not done.

The retry operation in the case of failure in processing at A and B in the figure is explained below:

• Retry operation in the case of failure in processing at A in the figure

  After sending a request from the redirector to the Web container for establishment of a connection, if the power supply to the host on which the Web container is running is disrupted or a network failure occurs, the operation is performed as follows:

  1. If the set timeout period elapses, a message indicating the occurrence of timeout during establishment of the connection is output.

  2. Retry establishing connection only for specified number of times.

  Note that if a connection cannot be established in spite of retrying for the specified number of times, a message indicating failure in sending request is output, and an error (status code 500) is returned to the client.

• Retry operation in the case of failure in processing at B part in the figure

  After a connection is established successfully, or the request header is sent to the Web container, if the power supply to the host on which the Web container is running is disrupted and a network failure occurs, perform the operation as follows:

  1. If the set timeout period elapses, a message indicating the occurrence of timeout when sending a request is output.

  2. Close the connection that was used for sending the request header.

  3. Retry sending the request header only for specified number of times.

     Note that at this point, the operation depends upon whether the connections are available in the connection cache.

     - When connections are available in the connection cache

     Use a connection in the connection cache and retry the process from sending the request header.

     - When there are no connections in the connection cache

     Re-establish a connection, and then retry sending the request header.

  Note that if the request header cannot be sent in spite of retrying for the specified number of times, a message indicating failure in sending request is output, and status code 500 is returned to the client.

• Retry operation when a request is distributed using a load balancer

  The following figure shows the retry operation when you use a load balancer to distribute a request:

  Note that in this figure, a request is first distributed to Web container 1 and then to Web container 2, and the retry frequency is set as three times.

  Figure 5‒18: Retry operation when a request is distributed using a load balancer

  The retry operation shown in the figure is as follows:

  1. Sending request to the Web container 1

     A request is sent to Web container 1. Retry operation is performed in the case of failure in establishing a connection to Web container 1, or failure in sending the request header. Retry is executed up to three times.

  2. Sending request to the Web container 2

     If the retry operation fails three times in Web container 1, the request is transferred to Web container 2. When the request is transferred, retry is counted again from 1, and hence, retry is executed up to three times even in Web container 2.

  3. Error notification to the client

     If the process of establishing a connection or sending the request header fails three times even in Web container 2, an error (status code 500) is returned to the client.

     Reference note

     A request is transferred only to the set number of Web containers.