qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleksandr Rudyy <oru...@gmail.com>
Subject Re: Failover
Date Fri, 16 Sep 2011 16:26:38 GMT
Hi all,

Me and Robbie created the following draft of Failover Policy for Qpid
Java Client.

Could you please comment on it?

Qpid Java Client Failover Policy

1. Qpid client failover basic principles.

When connection to broker is lost a Qpid client should be able to
re-establish connection to broker if failover policy is not switched
off by specifying "nofailover" as a failover option in a connection

The failover functionality on Qpid client should be based on principle
"stop the world".  When connection is lost and failover starts the
Qpid Client should not allow an invocation of any JMS operation which
requires sending or receiving data over the network. Such operations
should be blocked until failover functionality restores the
connectivity by using any of the supported failover methods
('singlebroker', 'roundrobin', 'failover_exchange').

On restoring connectivity blocked JMS operations should be allowed to
finish. If the failover functionality cannot re-establish the
connection a JMSException should be thrown within any JMS operation
requiring transferring data over the network.

On successful failover, it is expected that client JMS session should
restore all temporary queues(topics) if such were created before

2. Description of failover behavior for JMS operations

Session.commit() rollbacks transaction and throws a
TransactionRolledBackException if the session is dirty (there were
messages sent/received in the transaction) when failover occurred,
allowing the user to replay their transaction on the new Session.

Session.recover() and Message#acknowledge() should throw a
JMSException if there has been any message delivery since the last
acknowledgment was sent and failover occurred whilst the session was

Message consumer:

No further messages sent to the client by the old broker should be
received by the consumer after failover has occurred, only messages
sent by the new broker should be available to consumers.

Queue browser:

If failover occurred while iterating through QueueBrowser enumerations
a sub-class of NotSuchElementException should be thrown by default.

3. Issues with acknowledgments

The acknowledge operation should not return till all messages has
actually been acknowledged. Currently is possible for messages not
being acknowledged after invoking acknowledge operation. The
acknowledge is done lazily by acknowledgment flusher, however, this is
not what the JMS spec requires.


The JMS requires that after each call to receive operation or
completion of each onMessage the received message should be
acknowledged. Currently this does not happens as the acknowledge is
done lazily by acknowledgment flusher which does not give the same
guarantee. This is in fact is DUPS_OK_ACKNOWLEDGE behavior. The
flusher thread should not be running for AUTO_ACKNOWLEDGE.

Flusher thread is started but it is not really needed because
acknowledgment for transacted sessions is handled differently.
It seems that a flusher thread make sense to run in a


The flusher thread should not be running for NO_ACKNOWLEDGE.


The same issue as with AUTO_ACKNOWLEDGE.
Is anybody using this mode? Does it make sense to keep it?

Kind Regards,

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message