Active Connection Management (
ACM) is enabled by default and helps to improve scalability and conserve application resources by closing idle connections.
ACM is configured separately for client (outgoing) and server (incoming) connections using the properties
Ice.ACM.Client and
Ice.ACM.Server, respectively. The default value of
Ice.ACM.Client is
60, meaning an outgoing connection is closed if it has not been used for sixty seconds. The default value of
Ice.ACM.Server is zero, which disables ACM for incoming connections. Ice disables server ACM by default because it can cause incoming oneway requests to be silently discarded, as discussed in
Section 28.13.
The decision to close a connection is not based only on a lack of network activity. For example, a request may take longer to complete than the configured idle time. Therefore, ACM does not close a connection if there are outgoing or incoming requests pending on that connection, or if a batch request is being accumulated for that connection.
When it is safe to close the connection, it is done gracefully as described in Section 33.6. The closure is usually transparent to the client and server applications because the connection is reestablished automatically when necessary. We say connection closure is "usually transparent" because it is possible that the Ice run time will be unable to reestablish a connection for a variety of reasons (see
Section 33.4.2). In such a situation, the application receives a
ConnectFailedException for new requests, and
CloseConnectionException for pending requests.
It is important that you choose an idle time that does not result in excessive connection closure and reestablishment. The default value of sixty seconds is a reasonable default, but your requirements may determine a more appropriate value.
Since server ACM is disabled by default, you only need to set Ice.ACM.Client to 0 to disable ACM for all connections. In this configuration a connection is not closed until its communicator is destroyed or it is closed explicitly by the application (see
Section 33.5.4). It is important to note that disabling ACM in a process does not prevent a remote peer from closing a connection; all peers must be properly configured in order to truly disable ACM.
There are certain situations in which it is necessary to disable ACM. For example, oneway requests can be silently discarded when a connection is closed (see
Section 28.13). As another example, ACM must be disabled when using bidirectional connections. A bidirectional connection is enabled by using a router such as Glacier2 (see
Chapter 39) or by configuring a connection explicitly (see
Section 33.7). If you do not disable ACM in such cases, ACM can prematurely close a bidirectional connection and thereby cause callbacks to fail unexpectedly.
