Hi.
I'm about to commit a change that will alter the behaviour of the
AMQP 0-10 Java client during failover. To be specific, the mechanics
of client failover, despite some shared classes and packages
(FailoverPolicy for example) differ greatly between 0-8/0-9 and 0-10.
The earlier client connection delegate classes use of the
AMQProtocolHandler, as well as the FailoverHandler continuation which
ran after losing broker connectivity, is not present in the 0-10
delegate. This means that the CountdownLatch created and held by the
*protocol* handler is never created, so methods which try to call
AMQConnection#blockUntilNotFailingOver() or #isFailingOver() will
receive incorrect results.
I have raised QPID-3008 as follows:
https://issues.apache.org/jira/browse/QPID-3008
In the 0-10 Java client when a QueueBrowser returns an Enumeration,
and it is being enumerated over while the connection fails over,
the consumer cannot tell that failover is ocurring and sends
messages with incorrect subscriber tag numbers to the broker. The
BasicMessageConsumer_0_10 uses the shared
BasicMessageConsumer#acquireReceiving(boolean) method which tries
to call AMQConnection#isFailingOver() and #blockUntilNotFailingOver
() and receives incorrect results. This is because
AMQConnectionDelegate_0_10 does not start a FailoverHandler
continuation and therefore the AMQProtocolHandler#setFailoverLatch
(CountdownLatch) and associated methods are never called.
To correct this behaviour update the connection close method of the
0-10 delegate to create the latch, attempt failover and then
decrement and remove the latch on success.
I am fairly confident that this will not result in any issues with
the C++ broker failover or cluster behaviour, but would like to know
if anyone thinks this change could cause problems? The particular
test is QueueBrowserAutoAckTest#testFailoverWithQueueBrowser() and is
excluded only from the cpp.noprefetch profile, and this may be why...?
Finally, I note that while enumerating messages on a queue browser,
when it calls #receiveBrowse(), a 0-8 consumer will cause #receive(0)
to be called to obtain the next message, whereas a 0-10 consumer will
call #receiveNoWait() instead.
Can anyone tell me whether the blocking or non-blocking behaviour is
correct?
Cheerz,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
