Bug 812950 - Duplicate delivery after consumer failover in HA configuration.
Duplicate delivery after consumer failover in HA configuration.
Status: NEW
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid (Show other bugs)
2.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: messaging-bugs
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-16 12:24 EDT by Andrew Replogle
Modified: 2013-02-24 22:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Andrew Replogle 2012-04-16 12:24:00 EDT
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 12:51:30 EDT
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.