TCP transport channel custom properties
For a TCP transport channel, we can use TCP transport channel custom properties to configure internal TCP transport channel properties.
To add a TCP transport channel custom property, perform the following actions.
- In the console, click Servers > Server Types, and then follow one of the following paths:
- Application servers > server_name, and then select one of the following options, depending on the type of chain you are creating:
- Expand SIP container settings, and click SIP container transport chains.
- Expand Web container settings, and click Web container transport chains.
- (zos) Under Container services, and click ORB Service > ORB Service Transport Chains.
- Expand Server messaging, and click either Messaging engine inbound transports or WebSphere MQ link inbound transports.
- Proxy servers, and then expand HTTP proxy server settings, and click Proxy server transports and select either HTTPS_PROXY_CHAIN or HTTP_PROXY_CHAIN. Then click HTTP proxy inbound channel
- Select the transport chain that includes the TCP channel for which to specify the custom property.
- Select the TCP inbound channel.
- Click Custom properties > New, expand General properties, and specify the name of the custom property in the Name field and a value for this property in the Value field. We can also specify a description of this property in the Description field.
- Click Apply or OK.
- Click Save to save the configuration changes.
- Restart the server.
The following TCP transport channel custom property or properties is provided with the product. They are not shown on the settings page for a TCP transport channel.
Use the listenBacklog property to specify the maximum number of outstanding connection requests that the operating system can buffer while it waits for the application server to accept the connections. If a client attempts to connect when this operating system buffer is full, the connect request is rejected. The value of this property is specific to each transport.
If we need to control the number of concurrent connections, use the Maximum open connections field on the console TCP transport channel settings page.
Information Value Data type Integer Default 511
(zos) Note: The value you use for listenBacklog can be limited by the specification of the SOMAXCONN statement in the TCP/IP profile. If we use a listenBacklog value greater than the SOMAXCONN value, the listenBacklog value is not be used; the value for SOMAXCONN is used.
IMPORTANT: If listenBacklog is not set for channel types of HTTP, HTTP SSL, IIOP and IIOP SSL, the listenBacklog is set from deprecated environment values: protocol_http_backlog, protocol_https_backlog, protocol_iiop_backlog, and protocol_iiop_backlog_ssl. If the associated deprecated environment value is not specified, a default of 10 is used.
For channel types that are not HTTP, HTTP SSL, IIOP and IIOP SSL, the default for listenBacklog is 511.
Use the zaioFreeInitialBuffers property to indicate that the TCP channel should release the initial read buffers used on new connections as soon as these buffers are no longer needed for the connection. By default, this initial read buffer is cached for each connection. When a connection is closed, the read buffer is reused to avoid a memory allocation. This process works well for non-persistent connections, where there is one request per connection. However, for highly persistent connections, the buffer might be held for a considerable amount of time even though it is not being used. For workloads that require a large number of connected clients, this situation can cause a shortage of Language Environment (LE) heap space. Unless your workload consists mainly of non-persistent connections, you should set this custom property to true to enable the release of the initial read buffers.
If we set this property to true, you must also add the following argument to the JVM generic arguments configured for the application server that is using this TCP channel:-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Information Value Data type String Default false
Use the soReuseAddr custom property to control bind behavior. When the WAS is restarted, if the inbound TCP channels have problems trying to bind the listening socket, errors are printed into the SystemOut file until either the bind is successful or the number of allowed bind attempts has been passed. This custom property helps to avoid repeated error messages during the bind process.
For inbound TCP channel binding environments, we can avoid the repeated error messages using the SoReuseAddr custom property to affect TCP inbound channel processing. When SoReuseAddr is set to 1 , the TCP channel is forced to try each bind attempt with the re-use option set to true on the socket. The restart of the WAS processes first binding attempt, despite those sockets in TIME_WAIT state.
The first restart after applying the soReuseAddr property processes the previous instance of binding (which was bound with false). Two restarts might be required before re-use success is achieved with re-use set to true all the time. Also, we can wait until all the TIME_WAIT sockets have disappeared before restarting.
Information Value Data type Integer Default 0
(zos) Fine tuning the LE heap