ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

CA Gen Transaction Enabler (aefad/aefuf) processing limits


Article ID: 133311


Updated On:


Gen Gen - Run Time Distributed


This article aims to help understanding of the limits on users and applications that can be supported by the CA Gen Transaction Enabler (TE) (programs aefad and aefuf).. The article reflects the Unix/Linux operating system, although the same limitations will apply to the Windows operating system unless otherwise stated.


Release: CA Gen 8.5, 8.6

Component: Transaction Enabler


Connection Limitations for aefad


NOTE: Full details of the aefad including all start-up options (“AEFAD options”) can be found here: CA GEN 8.6 > Distributed Processing > Middleware > Transaction Enabler > AEF Asynchronous Daemon 

To handle connections, the aefad uses internal Control Structures which are allocated according to the values of the parameters -u and -a.

Total Control Structures allocated = -u parameter + -a parameter + 1

+1 is for one Control Structure used by aefad to "listen" for new connections.

-u represents the Maximum Number of "Users" (default value is 512). NOTE: This parameter no longer has any upper limit.

-a represents the Maximum Number of "Applications" (default value is 64 for Unix/Linux and 126 for Windows). Under Windows, the maximum for -a is 126. If a larger value is set for this parameter it will be ignored and the default value of 126 will be used instead.

NOTE: Each active Control Structure requires a 32KB communication buffer, so the memory resources on the server could indirectly impose a limit. For an example memory requirement for just the connected users see the aefad “-u Option Details” section: CA GEN 8.6 > Distributed Processing > Middleware > Transaction Enabler > AEF Asynchronous Daemon > -u Option Details


A "User" can be either an aefuf connection, an active transaction, an aefc session, or a client session.

The value of -u must be such that:

u >= # of aefufs + # of Active Transactions + # of aefcs + # of clients + 1

# of aefufs = The number of connected funnels

# of Active Transactions = The number of active load modules. Since it is impossible to determine at any given time when a load module could be active it is recommended to use the value for -a.

# of aefcs = The number of connected aefc clients i.e. aefc, aefcn.

# of clients = The number of users/clients connected to the aefad through the connected funnels. It is very advisable to not underestimate this value as it could have severe repercussions. Upon reaching the -u limit via client connections, ALL previously connected clients will be unable to have their transaction requests handled until the offending client connection or a currently connected client connection is dropped. A "client" can be a client manager, GUI client using TCPIP or any type proxy (C, Com or JAVA). Also, "clients" cannot directly connect to an aefad, only to the aefuf. The aefad does keep a list of clients for each aefuf, but not as such a direct connection between client and aefad.

+1 is allocated for use by the aefad.

In a proxy/web application environment where the number of client connections is harder to calculate, simply substitute the # of users with 245 per connected funnel. Each funnel can handle 245 active connections, so that is the "ceiling" is per funnel e.g. an aefad with 5 funnels and 20 aefcs, started with an -a of 126 would require:

u >= 5 + 126 + 20 + (5 *245) + 1 = 1377


An "Application" is a connected Load Module. Thus:

Active Applications = No. of connected Load Modules  NOTEActive Applications cannot be greater than the value of -a (Max. Applications).

Total Active Control Structures = Active Users + Active Applications + 1

Total Active Control Structures must be <= Total Control Structures allocated.


Connection Limitations for aefuf

NOTE: Full details of the aefuf including all start-up options (“AEFUF options”) can be found here: CA GEN 8.6 > Distributed Processing > Middleware > Transaction Enabler > AEF User Funnel

An aefuf will allocate a Control Structure for each Client connection and for its connection to the aefad. Thus:

Total Active Control Structures = No. of clients + 1

Each Control Structure will require a 32KB communication buffer. The internal limit of connections inside the aefuf is 245. This is less than the theoretical limit of 255 in previous versions. However, it was always recommended that users allocate no more than 250 connections per funnel to ensure that they do not go over the limit, as the aefuf would otherwise hang until the number of attempted connections dropped below the old limit. Changes were made to allow the aefuf to continue to service requests from existing connections while denying service to connections that go over the new 245 limit. This trade-off of 5 less connections per aefuf is to allow an "over-run" mechanism so that the aefuf will continue to operate.

The actual number of connections will be limited by the number of sockets the aefuf can use. (see below).

The addition of extra aefufs to enable increased capacity can sometimes be a challenge even with the use of a load balancer to bring the aefuf online. An alternative approach is to just have 1 aefuf and use non-persistent (transient) client connections instead of the default persistent client connections (the persistence setting is configured on the client side ). Using non-persistent connections does have the network overhead of the clients reconnecting for every flow and does put some overhead on the aefuf, so a barrage of new client connections will keep the aefuf quite busy. NOTE: If all client connections are transient the performance hit on the aefuf is unknown.


Use of sockets (aefad and aefuf)

On Unix/Linux the default communication method for the aefad and its load modules is TCP/IP sockets. There is NOT a one-one correspondence between the number of active Control Structures in an aefad and the number of sockets it has open. The connections that require a socket to be opened are only those to aefufs, Load Modules, and aefcs. The socket connection to a load module is reused by all transactions processed by that load module, so the transactions do not need a separate socket allocated. An aefc session only requires an aefad socket if it is connected directly to the aefad rather than the aefuf. Thus:

Active aefad sockets = # of connected aefufs + # of connected Load Modules + # of aefc' directly connected to aefad

Similarly, each aefuf allocates a socket for each connection to a client and aefad:

Active aefuf sockets = 1 connected aefad + No. of connected clients

On the Unix/Linux platform, each socket connection requires the opening/allocation of a file descriptor. Normally, the maximum number of open file descriptors globally and per Unix/Linux process is limited by kernel parameters. Compile time allocation of resources in aefad and aefuf effectively limits the maximum number of file descriptors that can be supported. For most platforms, aefad and aefuf set the maximum number of open file descriptors to 256. Out of this total, three are allocated to standard in, standard out, and standard error, but this number may be further limited by open trace files, log files, or security exits.

Thus, both aefad & aefuf have a maximum of 253 file descriptors for the allocation of sockets. TCP/IP resources can come into play on the various server platforms. If socket resources begin to be used up by large numbers of active transactions, aefuf gives priority to outbound traffic (flowing from the servers to the clients). This causes client-to-server messages to wait in the aefuf processes or in the client systems until resources become available on the server platform.

NOTE: Under older releases of the TE on Unix, the aefad could be started with a -r parameter that would cause the aefad to use Unix Pipes to communicate with load modules instead of sockets. This feature was removed as of Gen 6.5 and only sockets are now supported for Unix.

On Windows the main difference is that the aefad uses Inter-Process Communication (IPC) logic to communicate with its load modules and as such does not use sockets. So the formula for determining the number of sockets a TE running under Windows would use is as follows:

Active aefad sockets = # of connected aefufs + # of aefcs directly connected to aefad

Similarly, each aefuf allocates a socket for each connection to a client and aefad:

Active aefuf sockets = 1 connected aefad + No. of connected clients


aefad and concurrent transaction requests

The internal mechanism of the aefad can handle concurrent transaction requests coming from multiple clients via multiple aefufs or aefcs. It will allocate a handle to keep track of each request coming in and going back to the client/aefc. There is a limit on this however, and any request exceeding the limit will be rejected. The limit is 256 simultaneous transactions at any moment in time. If this limit is reached frequently in a given TE environment, the recourse is to start another aefad to accommodate the coverage.

Additional Information

CA Gen Transaction Enabler: CA GEN 8.6 > Distributed Processing > Middleware > Transaction Enabler