When the openWarn or idleWarn specified threshold is exceeded, the broker will log a WARN level alert with details of the connection on which the threshold has been exceeded, along with the age of the transaction.

When the openClose or idleClose specified threshold value is exceeded, the broker will throw an exception back to the client connection via the ExceptionListener, log the action and then close the connection.

The example broker log output shown below is where the idleWarn threshold specified is lower than the idleClose threshold and the broker therefore logs the idle transaction 3 times before the close threshold is triggered and the connection closed out.

CON-1011 : Idle Transaction : 13,116 ms
CON-1011 : Idle Transaction : 14,116 ms
CON-1011 : Idle Transaction : 15,118 ms
CON-1002 : Close : Idle transaction timed out
   

The second example broker log output shown below illustrates the same mechanism operating on an open transaction.

CON-1010 : Open Transaction : 12,406 ms
CON-1010 : Open Transaction : 13,406 ms
CON-1010 : Open Transaction : 14,406 ms
CON-1002 : Close : Open transaction timed out
   

After a Close threshold has been exceeded, the Broker will close the client's connection. The application must reconnect itself in order to continue work. If the client is a JMS client, the application will be notified by the exception listener.

The transaction timeouts can be specified when a new virtualhost is created or an exiting virtualhost is edited.

We would recommend that only warnings are configured at first, which should allow broker administrators to obtain an idea of the distribution of transaction lengths on their systems, and configure production settings appropriately for both warning and closure. Ideally establishing thresholds should be achieved in a representative UAT environment, with clients and broker running, prior to any production deployment.

It is impossible to give suggested values, due to the large variation in usage depending on the applications using a broker. However, clearly transactions should not span the expected lifetime of any client application as this would indicate a hung client.

When configuring closure timeouts, it should be noted that a timeout on any producer or consumer will cause the connection to be closed - this disconnecting all producers and consumers created on that connection.