dfhtl_cwspersistent.html |
Last updated: Thursday, 27 June 2019When a connection is made between a web client and CICS® as an HTTP server, or between CICS as an HTTP client and a server, by default CICS attempts to keep the connection open as a persistent connection.
In a TCPIPSERVICE resource definition for CICS web support, the SOCKETCLOSE and MAXPERSIST attributes of the TCPIPSERVICE definition should not be specified as zero. A zero setting for SOCKETCLOSE means that CICS as an HTTP server closes the connection immediately after receiving data from the web client, unless further data is waiting. A zero setting for MAXPERSIST means that CICS requires every web client to close the connection after they receive each response from CICS. In either of these situations, persistent connections cannot be maintained. Only use zero settings for these attributes if you have a special requirement for them in a CICS region that is not currently handling external requests, for example in a test environment.
If the user application program needs to test whether the server has requested termination of the connection, the READ HTTPHEADER command can be used to look for the Connection: close header in the last message from the server. If the server requests closure of the connection, but the application program has not yet issued a WEB CLOSE command, CICS closes the connection but maintains the data relating to the connection (including the last response received from the server and its HTTP headers). The application program can continue to use that data until it issues a WEB CLOSE command or end of task is reached.
When the user application program issues the WEB CLOSE command to end its use of the connection, if the connection is still open CICS does not necessarily close it. If connection pooling was not specified for the connection, or if the connection is not in a good state for connection pooling, CICS does close the connection. However, if connection pooling was specified in the URIMAP resource that was used to open the connection, and the connection is in a good state, CICS does not close the connection. Instead, CICS places the connection in a pool of dormant connections, and it can be reused by another application program or by another instance of the same application program to connect to the same server. See CICS as an HTTP client: Connection pooling for outbound HTTP connections for more information about connection pooling.
If CICS as an HTTP client is communicating with an HTTP/1.0 server, CICS automatically sends Connection: Keep-Alive headers on HTTP messages. The application program that requested the connection does not need to provide these. Keep-Alive informs the server that a persistent connection is required.
If multiple web clients set up long-lived persistent connections to CICS as an HTTP server and use the connections heavily, it is possible for a CICS region handling the connections to become overloaded and experience performance problems. If you experience this problem, you can set up connection throttling to make excess web clients connect to other CICS regions that share the port and provide the same service.
With connection throttling, you can set a limit on the number of persistent HTTP connections that a CICS region accepts for a particular port. If the limit is reached and further web clients send requests, CICS sends Connection: close headers with each response to require the new clients to close their connection. The web clients that already have persistent connections to the CICS region can maintain their persistent connections. When the new clients reconnect, if they connect to another CICS region that shares the port and has not reached its limit, they can maintain a persistent connection there. The CICS region that has reached its limit begins to accept new persistent connections again when the web clients that have persistent connections to it close their connections.
Connection throttling is managed by the MAXPERSIST attribute on the TCPIPSERVICE resource definition for the port. The default setting, MAXPERSIST(NO), means that there is no limit on the number of persistent connections that the CICS region accepts. To set up connection throttling, specify a suitable value for the MAXPERSIST attribute based on the number of persistent connections that the CICS region can handle simultaneously. The setting applies only to the HTTP and HTTPS protocols, not to any other protocol.
An HTTP/1.1 server should normally allow persistent connections, so only set up connection throttling in a CICS region that has experienced performance problems due to long-lived persistent connections. A zero setting for MAXPERSIST, meaning that the CICS region does not allow any persistent connections, is not compliant with the HTTP/1.1 specification. Only use a zero setting if you have a special requirement for it in a CICS region that is not currently handling external requests, for example, in a test environment. When you specify a value greater than zero for MAXPERSIST, CICS as an HTTP server is still compliant with the HTTP/1.1 specification: the default behavior is still to allow persistent connections, and web clients receive a Connection: close header if they cannot obtain a persistent connection. However, you should be aware that refusing persistent connections is not recommended as a normal practice for an HTTP/1.1 server. Also be aware that the performance of web clients can be affected when they fail to obtain a persistent connection that they expected.
By default, CICS closes a client HTTP connection after a CICS application has finished using the connection, or a service requester application has made a web service request and received a response, or the HTTP EP adapter has emitted a business event. When you set up connection pooling, instead of closing the connection CICS can place the connection in a pool in a dormant state. The dormant connection can be reused by the same application or by another application that connects to the same host and port. Connection pooling can provide performance benefits where multiple invocations of CICS web support applications, web services applications, or the HTTP EP adapter make connection requests to a particular host and port, or where a web services application makes multiple requests and responses.
To set up connection pooling, you specify the SOCKETCLOSE attribute on a URIMAP resource definition for the client HTTP connection. For a client HTTP connection to be pooled, the CICS application program must specify the URIMAP resource on the INVOKE SERVICE or WEB OPEN command, and CICS web support applications must issue the WEB CLOSE command to explicitly end their use of the connection. A connection cannot be pooled if the server has requested CICS to close the connection, or if the application program has requested the server to close the connection by specifying the CLOSESTATUS(CLOSE) option on the WEB SEND or WEB CONVERSE command. CICS also checks the state of an open connection before placing it in the pool; connections are not pooled if they are found or suspected to be in a poor state, for example, if the last HTTP response was not OK.
When an application uses a URIMAP resource to make a client HTTP connection, CICS checks whether a dormant connection is available in the pool for that host and port, and if so supplies it to the application rather than opening a new connection. Applications reuse a pooled connection in exactly the same way as they use a new connection, and the connection can be pooled again after use. If a connection reaches the time limit that you specified in the SOCKETCLOSE attribute without being reused, CICS discards it. CICS also closes dormant connections in the pool if MAXSOCKETS is reached for the CICS region, or if you discard the URIMAP resource for the connection, or if the server requests CICS to close the connection.
Last updated: Thursday, 27 June 2019