Bug 812950 - Duplicate delivery after consumer failover in HA configuration.
Summary: Duplicate delivery after consumer failover in HA configuration.
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid
Version: 2.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-16 16:24 UTC by Andrew Replogle
Modified: 2022-11-29 08:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)
test client for pausing before acking allowing time to kill connected broker. (621 bytes, text/x-python)
2012-04-16 16:24 UTC, Andrew Replogle
no flags Details

Description Andrew Replogle 2012-04-16 16:24:00 UTC
Created attachment 577764 [details]
test client for pausing before acking allowing time to kill connected broker.

Description of problem:
Using connection.reconnect=True if a consumer goes to fetch a message off a broker in an HA cluster and the broker fails before the acknowledgement, the failed over broker doesn't remove the message from the queue after the acknowledgement. 


Version-Release number of selected component (if applicable):
qpid-cpp-server-cluster-0.12-6.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Connect to an HA cluster (using connection.reconnect = True) and fetch a message (don't ack).
2. Kill the broker you're connected to.
3. Acknowledge the message after your connection/session is failed over.
4. Examine the queue and see that your message is still on the queue even though you acknowledged w/out error.
  
Actual results:
No error, message is delivered to client but message is not removed from queue. 

Expected results:
After session.acknowledge the message is removed from the queue.

Additional info:

Comment 1 Gordon Sim 2012-04-16 16:51:30 UTC
This is really a messaging API issue. The call to acknowledge will not fail after reconnecting, even though the set of messages it actually refers to may have been changed by the failover. How best to signal this fact to the application this needs some further thought and debate.


Note You need to log in before you can comment on or make changes to this bug.