This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 509994 - browsed, cluster durable lvq loses order between persistent and transient messages
browsed, cluster durable lvq loses order between persistent and transient mes...
Status: NEW
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.1.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: messaging-bugs
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-07 06:22 EDT by Gordon Sim
Modified: 2013-02-24 08:23 EST (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Gordon Sim 2009-07-07 06:22:15 EDT
Description of problem:

If due to a browsing subscriber, more than one message exists on queue for a given key and the later message was sent as persistent while the earlier message was sent as transient, then if cluster durability is triggered, and the resulting store used for recovery the newer message will be replaced by the older message.

Version-Release number of selected component (if applicable):

qpidd-0.5.752581-22.el5

How reproducible:

100%

Steps to Reproduce:
1. start two node cluster
2. create cluster durable lvq
   e.g.  qpid-config add queue test-queue --order lvq --durable --cluster-durable
3. send transient message to the queue
   e.g. echo one | sender --lvq-match-value abc
4. browse the queue (prevents replacement of the previous message)
   e.g. receiver --browse --messages 1
5. send a durable message with same key
   e.g. echo two | sender --lvq-match-value abc --durable true
6. kill one node to trigger cluster-durable feature
7. stop and recover the remaining node
  
Actual results:

After recovery, only the older message remains on the queue (i.e. one). The newer message has been incorrectly overridden.

Expected results:

Always have the latest message on the queue.

Additional info:

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