Qpid connections support a failover feature. This is the ability to automatically re-establish a failed connection, either to the same Broker, or the next Broker in the broker list.

This failover process is done in a manner that is mostly transparent to the application. After a successful failover, any existing Connection, Session, MessageConsumer and MessageProducer objects held by the application remain valid.

If a failover occurs during the scope of a JMS Transaction, any work performed by that transaction is lost. The application is made aware of this loss by way of the TransactionRolledBackException from the Session#commit() call. Applications utilising failover must be prepared to catch this exception and respond by either repeating the work of the transaction, or by propagating a rollback to the originating system.

If, after all retries are exhausted, failover has failed to reconnect the application, the Connection's ExceptionListener will receive a JMSException with a linked exception of AMQDisconnectedException. Any further use of the JMS objects (Connection, Session etc), will results in a IllegalStateException.

Configure failover using the Connection URL. Here's an example Connection URL utilising failover between two brokers. Note the use of the broker options retries and connectdelay to control the number of connection attempts to each individual broker, and the delay between each connection attempt. Also note the use of the failover option cyclecount to control the number of times the failover mechanism will traverse the brokerlist.

amqp://username:password@clientid/test
            ?brokerlist='tcp://localhost:15672?retries='10'&connectdelay='1000';tcp://localhost:25672?retries='10'&connectdelay='1000''
            &failover='roundrobin?cyclecount='20''
        

For full details see Chapter 7, Connection URLs

amqp://username:password@clientid/test
            ?brokerlist='tcp://localhost:15672?failover='nofailover'
        

Qpid connections support heartbeating. When enabled, the Client and Broker exchange a heartbeat during periods of inactivity. This allows both peers to discover if the TCP/IP connection becomes inoperable in a timely manner.

This feature is sometimes useful in applications that must traverse firewalls as the heartbeat prevents connections from being closed during periods when there is no application traffic.

It is also allows the both the JMS client and the Broker to confirm that the other is minimally responsive. (It does nothing however to determine the health of the higher level tiers of application, for this reason, applications may implement an application level heartbeat either in addition to, or instead of the heartbeat.

If the client ever fails to receive two consecutive heartbeats, the Connection will be automatically closed and the Connection's ExceptionListener will receive a JMSException with a linked exception of AMQDisconnectedException. Any further use of the JMS objects (Connection, Session etc), will results in a IllegalStateException.

To enable heartbeating either use a Connection URL including the broker option heartbeat, or use the system property qpid.heartbeat.

amqp://guest:guest@clientid/?brokerlist='localhost:5672?heartbeat='5''
        

The Client supports connections encrypted using Secure Socket Layer (SSL) and SSL-Client Authentication. SSL is configured using Connection URL. To use SSL, SSL must be be configured on the Broker.

Some example Connection URLs using SSL follow:

The client has the ability to transparently compress message payloads on outgoing messages and decompress them on incoming messages. In some environments and with some payloads this feature might offer performance improvements by reducing the number of bytes transmitted over the connection.

In order to make use of message compression, the Broker must enable the feature too, otherwise the compression options will be ignored.

To enable message compression on the client use the connection url property compressMessages (or JVM wide using the system property qpid.connection_compress_messages)

It is also possible to control the threshold at which the client will begin to compress message payloads. See connection url property messageCompressionThresholdSize (or JVM wide using the system property qpid.message_compression_threshold_size)