You can set the timeout period in the Web server, for receiving a request transferred from the client. You can detect the occurrence of failure in the client by using the communication timeout that was set up. You can detect the following failures:

Detectable failures

• The host on which the client is running is down.
• A network failure occurs between the client and the Web server.
• A failure occurs in client application.

You can set the timeout period in the redirector, for sending a request to the Web container. When the set timeout period is exceeded and a timeout occurs, a message is output to the error log of Cosminexus HTTP Server.

(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 4-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.

Hint

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 4-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.

You can set a timeout period in the Web container, for receiving a request transferred from the redirector. You can detect the occurrence of failure in the redirector using the communication timeout that was set up. You can detect the following failures:

Detectable failures

• The host on which the Web server is running is down.
• A network failure occurs between the Web server and the Web container.
• Timeout occurred in the Web container before the processing between the client and the Web server completes.
  This implies that when the data size requested by the Web container was being read between the client and the Web server, the communication timeout set in the Web container occurred before the data is read completely, due to insufficient communication speed between the client and the Web server.
  

The following table describes the conditions for occurrence of communication timeout and the operations after the timeout occurs.

Table 4-13 Conditions for occurrence of communication timeout and the operations after occurrence

Conditions for occurrence of communication timeout	Operations after occurrence
In the case all the following conditions are satisfied when a request is received: The request contains a body data. The body data is not in the chunk format. After the reading process starts, a failure occurs in the host on which the redirector is running, or in the network between the redirector and the Web container.	Request is not processed. Message KDJE39188-E is output to the message log.
In the case all the following conditions are satisfied when using API# in the servlet (JSP): The request contains a body data. The body data is not in the chunk format. After the reading process starts, a failure occurs in the host on which the redirector is running, or in the network between the redirector and the Web container.	java.lang.IllegalStateException occurs. The connection to the redirector is closed, and thereafter you cannot read or write the data. Message KDJE39188-E is output to the message log.
In the case all the following conditions are satisfied when POST data is read by using the java.io.BufferedReader class acquired by getReader method of javax.servlet.ServletRequest class or javax.servlet.ServletInputStream class in the servlet (JSP): The request contains a body data. After the reading process starts, a failure occurs in the host on which the redirector is running, or in the network between the redirector and the Web container.	java.net.SocketTimeoutException occurs. The connection to the redirector is closed, and thereafter you cannot read or write the data. Message KDJE39188-E is output to the message log.

#

Indicates the case of using the getParameter method, getParameterMap method, getParameterNames method, and getParameterValues method of javax.servlet.ServletRequest.