Timeout Considerations for EntireX Broker

Any broker stub application that issues a LOGON but does not issue a REGISTER is a client. During logon, broker allocates resources to each client and keeps them available to the client until the client application issues a LOGOFF. A client is considered inactive when it is not issuing a broker request. A typical example of a broker request by a client is the SEND function.

The CLIENT-NONACT value defines the maximum period of time a client can remain inactive. See CLIENT-NONACT under Broker Attributes. If the client continues to be inactive beyond this period of time, Broker releases all the resources allocated to this client. This time is a global attribute, applicable to all clients of the Broker.

Any broker stub application that issues a LOGON and also issues a REGISTER is a server. During logon and registration, broker allocates resources to each server, and keeps them available to the server until the server issues a DEREGISTER and LOGOFF. A server is considered inactive when it is not issuing a broker request. A typical example of a Broker request by a server is the RECEIVE function.

The SERVER-NONACT value defines the maximum period of time a server can remain inactive. See SERVER-NONACT under Broker Attributes. If the server continues to be inactive beyond this period of time, Broker releases all the resources allocated to this server. This time is a per-service attribute, and can vary from one service definition to another. All servers, registered to the same service, inherit the same SERVER-NONACT time. If a server registers to more than one service, the highest SERVER-NONACT value is taken as the non-activity time period.

A conversation begins when a client successfully sends a message addressed to a server. The Broker allocates a unique conversation, even before the server receives this message. Broker also allocates resources to manage each conversation. A conversation remains active as long as messages are being exchanged with this conversation ID. The conversation remains inactive as long as neither a client nor a server makes a Broker request, referencing this conversation ID. The resources allocated to a conversation are freed when either a client or a server issues EOC.

The CONV-NONACT value defines the maximum period of time a conversation can remain inactive. If the conversation continues to be inactive beyond this period of time, Broker releases all the resources allocated to this conversation.

Each UOW has a lifetime value associated with it. This is the time that a UOW is allowed to exist without being completed. A UOW is completed when it is successfully

• either cancelled or backed out by its sender

• or cancelled or committed by its receiver.

If a UOW is in ACCEPTED status when this lifetime expires, the UOW is placed into a timeout status. Lifetime timeouts will not occur when the UOW is in either RECEIVED or DELIVERED status. See CONV-NONACT description in Relationship between Timeout Values.

If Entire Net-Work is used to transmit a Broker request, the setting of the Entire Net-Work NODE statement parameter REPLYTIM may influence the behavior of the application (see your Entire Net-Work documentation for details). All non-activity timeouts in the Broker configuration should be considered when determining the maximum time. This maximum time should be less than the value defined for REPLYTIM in the Entire Net-Work configuration.