このコンテンツは選択した言語では利用できません。
Chapter 10. Detecting Dead Connections
Sometimes clients stop unexpectedly and do not have a chance to clean up their resources. If this occurs, it can leave resources in a faulty state and result in the broker running out of memory or other system resources. The broker detects that a client’s connection was not properly shut down at garbage collection time. The connection is then closed and a message similar to the one below is written to the log. The log captures the exact line of code where the client session was instantiated. This enables you to identify the error and correct it.
[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession] I'm closing a JMS Conection you left open. Please make sure you close all connections explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession] The session you didn't close was created here:
java.lang.Exception
at org.apache.activemq.artemis.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
at org.acme.yourproject.YourClass (YourClass.java:666) 1- 1
- The line in the client code where the connection was instantiated.
Detecting Dead Connections from the Client Side
As long as it is receiving data from the broker, the client considers a connection to be alive. Configure the client to check its connection for failure by providing a value for the client-failure-check-period property. The default check period for a network connection is 30000 milliseconds (30 seconds), while the default value for an In-VM connection, is -1, which means the client never fails the connection from its side if no data is received.
Typically, you set the check period to be much lower than the value used for the broker’s connection time-to-live, which ensures that clients can reconnect in case of a temporary failure.
The examples below show how to set the check period to 10000 milliseconds (10 seconds) using Core JMS clients.
Procedure
Set the check period for detecting dead connections.
If you are using JNDI with your Core JMS client, set the check period within the JNDI context environment,
jndi.properties, for example, as below.java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory connectionFactory.myConnectionFactory=tcp://localhost:61616?clientFailureCheckPeriod=10000
If you are not using JNDI set the check period directly by passing a value to
ActiveMQConnectionFactory.setClientFailureCheckPeriod().ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactory(...) cf.setClientFailureCheckPeriod(10000);
10.1. Connection Time-To-Live
Because the network connection between the client and the server can fail and then come back online, allowing a client to reconnect, AMQ Broker waits to clean up inactive server-side resources. This wait period is called a time-to-live (TTL). The default TTL for a network-based connection is 60000 milliseconds (1 minute). The default TTL on an In-VM connection is -1, which means the broker never times out the connection on the broker side.
Configuring Time-To-Live on the Broker
If you do not want clients to specify their own connection TTL, you can set a global value on the broker side. This can be done by specifying the connection-ttl-override element in the broker configuration.
The logic to check connections for TTL violations runs periodically on the broker, as determined by the connection-ttl-check-interval element.
Procedure
Edit BROKER_INSTANCE_DIR/etc/broker.xml by adding the
connection-ttl-overrideconfiguration element and providing a value for the time-to-live, as in the example below.<configuration> <core> ... <connection-ttl-override>30000</connection-ttl-override> 1 <connection-ttl-check-interval>1000</connection-ttl-check-interval> 2 ... </core> </configuration>
- 1
- The global TTL for all connections is set to
30000milliseconds (30 seconds). The default value is-1, which allows clients to set their own TTL. - 2
- The interval between checks for dead connections is set to
1000milliseconds (1 second). By default, the checks are done every2000milliseconds (2 seconds).
Configuring Time-To-Live on the Client
By default clients can set a TTL for their own connections. The examples below show you how to set the Time-To-Live using Core JMS clients.
Procedure
Set the Time-To-Live for a Client Connection.
If you are using JNDI to instantiate your connection factory, you can specify it in the xml config, using the parameter
connectionTtl.java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory connectionFactory.myConnectionFactory=tcp://localhost:61616?connectionTtl=30000
If you are not using JNDI, the connection TTL is defined by the
ConnectionTTLattribute on aActiveMQConnectionFactoryinstance.ConnectionFactory cf = ActiveMQJMSClient.createConnectionFactory(...) cf.setConnectionTTL(30000);
10.2. Disabling Asynchronous Connection Execution
Most packets received on the broker side are executed on the remoting thread. These packets represent short-running operations and are always executed on the remoting thread for performance reasons. However, some packet types are executed using a thread pool instead of the remoting thread, which adds a little network latency.
The packet types that use the thread pool are implemented within the Java classes listed below. The classes are all found in the package org.apache.actiinvemq.artemis.core.protocol.core.impl.wireformat.
- RollbackMessage
- SessionCloseMessage
- SessionCommitMessage
- SessionXACommitMessage
- SessionXAPrepareMessage
- SessionXARollbackMessage
Procedure
To disable asynchronous connection execution, add the
async-connection-execution-enabledconfiguration element to BROKER_INSTANCE_DIR/etc/broker.xml and set it tofalse, as in the example below. The default value istrue.<configuration> <core> ... <async-connection-execution-enabled>false</async-connection-execution-enabled> ... </core> </configuration>
10.3. Closing Connections from the Client Side
A client application must close its resources in a controlled manner before it exits to prevent dead connections from occurring. In Java, it is recommended to close connections inside a finally block:
Connection jmsConnection = null;
try {
ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(...);
jmsConnection = jmsConnectionFactory.createConnection();
...use the connection...
}
finally {
if (jmsConnection != null) {
jmsConnection.close();
}
}