qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject QPID-3008 / 0-10 Java Client Failover / Queue Browser Oddity
Date Thu, 20 Jan 2011 00:57:06 GMT

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:

> 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  

-- 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:dev-subscribe@qpid.apache.org

View raw message