aefad parameters for TCP/IP Send/Receive buffer sizes & Web Service feature
Article ID: 38970
Updated On:
Products
Issue/Introduction
In Gen 8.5 via a series of PTFs, two new parameters were add to the Gen Transaction Enabler aefad. These parameters allow users to:
- Set the size of the TCP/IP Send/Receive buffers that the TE uses when communicating between the aefad and aefuf.
- Disable the Web Service feature of the TE.
This article is designed to assist users to better understand these parameters and how and when to use them.
The 8.5 PTFs that introduced these new parameters were:
RTN85015 - Windows
RTI85303 - HP-UX Itanium
RTL85303 - Solaris
RTR85303 - AIX
RTX85303 - Linux
Environment
Gen Transaction Enabler.
Resolution
TCP/IP Send/Receive
The Transaction Enabler uses TCP/IP sockets to communicate between the Clients and aefuf, aefuf and aefad as well as between the aefad and cooperative Load Modules (Unix only).
TCP/IP communication like this is subject to the amount of space reserved by the TCP/IP stack for the applications and during periods of heavy throughput between the various processes, this reserved space will become insufficient. Only by starting with larger Send/Receive buffers can applications hope to have enough reserved space on the TCP/IP stack for data transmission.
Prior to the PTFS, the TE's internal mechanism for setting the size of the Send/Receive buffers was to use the default settings on the host system. Users could influence the size of the buffers by making system wide changes to the defaults and the TE would use them at startup time.
Applications using TCP/IP communications can set the buffer size without relying on the system settings and it was decided to allow users to control what the TE allocates for the buffer size. This was done by adding the startup parameter -b to both the aefad and aefuf processes. The -b parameter tells the processes to allocate Send and Receive buffers in 65K increments depending on the value of the parameters e.g. to allocate 10 increments:
-b 10 = 656,000 bytes.
- If not set by the user, the default value for b is 1. Therefore, a minimum of 65k bytes will be allocated.
- The maximum permitted value for b is 100.
- The same parameter exists for both the aefuf and aefad and it is recommended that its value be the same for both processes.
- The parameter must be set at startup of the process.
Setting the parameter and implications:
The algorithm used by the aefad and aefuf to set the Send/Receive buffers based on the parm value of -b is as follows:
- If the system default value is greater than or equal to the value of parm*65k, the process will use the system setting.
- If the system default value is less than the value of the parm*65k, the process will use the user setting with following caveat:
- If the system rejects the user value for any reason, the process will run with the system default value.
To determine what happens when using a certain value and what decision the TE makes on how to use the value, start the TE (both the aefuf and aefad) with logging (ex. -t31). In the log files will be messages (see below) that will show how the TE processed the -b parameter.
Here is an example of an aefad log file where the system default value is 131k for the Send buffer and 1024k for the Receive buffer.
The user set the -b to 2 and the aefad determined that for the Send buffer the user value higher is than the system default and that for the Receive buffer the system default was higher than the user value:14:29:03.520===>aefad: SYSTEM SND_BUF (131072) < USER setting(-b2 * 65536)...using USER14:29:03.520===>aefad: SYSTEM RCV_BUF (1024000) > USER setting(-b2 * 65536)...using SYSTEM
If the user selects a value for the -b parameter that the system, for some reason cannot allow, they would see the following message in the trace log that the system default will be used:14:32:17.683===>aefad: Buffersize (10240000) rejected by the system
The value to use for this parameter depends on the following factors:
- The number of aefuf processes connected to a single aefad process.
- The maximum number of cooperative load modules started by a aefad process as determined by the -a parameter.
- The number of concurrent user requests at any given time.
In many cases, the default value will suffice and these factors should be considered before changing it:
- Currently there are no metrics for the various values of this parameter.
- Users should consider the factors stated above and increase the value of the -b parameter.
- Setting the limit too high could have negative impact on performance.
- If the value chosen is rejected by the Socket API call, it will result in the default system value being used. Users can experiment with the implications of this parameter by also starting the aefuf and aefad with the addition of a -t31 parameter and look in the resultant log file (see above).
TE Web Services
By default, the TE will accept properly formatted SOAP requests from Clients. This behavior was first introduced in Gen 8.5. Web Service requests, like all other Client requests must go through the aefuf process and NOT directly to the aefad. Web Service requests directly to the aefad will be rejected with one of the following error messages:
TIRM030E: Application failed - Updates have been backed out ODC: (Transport-WS:55) "Send failure: Connection was reset" occurred in handleComm(WS)().
OR
TIRM030E: Application failed - Updates have been backed out ODC: (Transport-WS:56) "Recv failure: Connection was reset" occurred in handleComm(WS)().
In the above referenced PTFs, users have the ability to disable the Web Service with the parameter -n. The default value is -n1, which means that this TE will accept Web Service requests. A value of -n0 will disable this feature and any Web Service requests will be rejected by the TE and the Client will receive this type of error:
TIRM030E: Application failed - Updates have been backed outCSU-GENERAL-ERROR: WsErrorParser::parse(): SAXParseException (line: 1, col: 1) caught: 'invalid document structure'.
Additional Information
Feedback
