New 8.5 Transaction Enabler parameters for TCP/IP Send/Receive buffer sizes & Web Service feature.

Products

• Gen
• Gen - Workstation Toolset
• Gen - Host Encyclopedia
• Gen - Run Time Distributed

Issue/Introduction

Introduction:

In Gen 8.5 via a series of PTFs, two new parameters were add to the Transaction Enabler. These parameters allow users to:

1. Set the size of the TCP/IP Send/Receive buffers that the TE uses when communicating between the aefad and aefuf. 
2. Disable the WebService 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 are:

RTN85015 - Windows

RTI85303 -  HP-UX Itanium

RTL85303 -  Solaris

RTR85303 - AIX

RTX85303 - Linux

 

Instructions:

1. 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 you use a certain value and what decision the TE makes on how to use the value, you must start the TE (both the aefuf and aefad) with logging (ex. -t31). In the logfiles you will see messages (see below) that will show how the TE processed the -b parameter.

Here is an example of an aefad logfile where the system default value is 131k for the Send buffer and 1024k for the Receive buffer. The user set the -b to 2. You can see that the aefad for the Send buffer determined that the user value higher than the system default and that the system default for the Receive buffer was higher than the user value. 

14:29:03.520===>aefad: SYSTEM SND_BUF (131072) < USER setting(-b2 * 65536)...using USER 

14: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).

2. TE WebServices:

By default, the TE will accept properly formatted SOAP requests from Clients. This behavior was introduced in Gen 8.5. WebService requests, like all other Client requests must go through the aefuf process and NOT directly to the aefad. WebService 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 WebService with the parameter -n. The default value is -n1, which means that this TE will accept Webservice requests. A value of -n0 will disable this feature and any WebService requests will be rejected by the TE and the Client will receive this type of error:

TIRM030E: Application failed - Updates have been backed out

CSU-GENERAL-ERROR: WsErrorParser::parse(): SAXParseException (line: 1, col: 1) caught: 'invalid document structure'.

 

                            

Environment

Release: KGNDDL99000-8.5-Gen-DBP Developer License
Component: