Bug 484218 - Need for configurable LVQ property
Need for configurable LVQ property
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.1
All Linux
high Severity medium
: 2.0
: ---
Assigned To: Gordon Sim
Petr Matousek
IG Index
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-05 09:28 EST by Arnaud Simon
Modified: 2011-06-23 11:44 EDT (History)
5 users (show)

See Also:
Fixed In Version: qpid-cpp-0.9.1079953
Doc Type: Bug Fix
Doc Text:
Cause: LVQ was hardcoded to use a specific message header as the key determining equivalence (qpid.LVQ_key) Consequence: Producers need to be explicitly coded to set that header (implying they need to know they are using an LVQ). Would prefer to use an application defined header as the key. Fix: New configuration option added to allow the choice of LVQ key to be set per-queue (qpid.last_value_queue_key) Result: Users can choose an application defined header (with more real significance) as the basis for message replacement/update. Producers will be setting such headers anyway and are thus free from explicit alteration for LVQ.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-23 11:44:57 EDT
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 Arnaud Simon 2009-02-05 09:28:51 EST
Description of problem:
Currently an LVQ only uses the property qpid.LVQ_key. There are two problems with that:
1) The message producer needs to know that its messages are sent to a LVQ
2) JMS message selector cannot be applied on properties that contain a "." (as per SQL92) 

How to fix it: 
It would be nice to define the property that is used by a LVQ when creating the queue itself. So, this would solve the 2 issues listed above as an existing property that does not contain a "." can be used.
Comment 1 Gordon Sim 2011-03-02 09:51:06 EST
Fixed in conjunction with bug 632000. The qpid.last_value_queue_key allows this option to be set (and also triggers improved behaviour as described in bug 632000).
Comment 2 Gordon Sim 2011-03-07 09:35:35 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:
LVQ was hardcoded to use a specific message header as the key determining equivalence (qpid.LVQ_key)

Consequence:
Producers need to be explicitly coded to set that header (implying they need to know they are using an LVQ). Would prefer to use an application defined header as the key.

Fix:
New configuration option added to allow the choice of LVQ key to be set per-queue (qpid.last_value_queue_key)

Result:
Users can choose an application defined header (with more real significance) as the basis for message replacement/update. Producers will be setting such headers anyway and are thus free from explicit alteration for LVQ.
Comment 3 Justin Ross 2011-03-15 17:17:23 EDT
Fixed upstream at 1069322.  See https://issues.apache.org/jira/browse/QPID-2104 .
Comment 5 Petr Matousek 2011-05-27 08:25:42 EDT
This issue has been fixed.

Verified on RHEL5.6, RHEL6.1 architectures: i386, x86_64

packages installed:
python-qpid-0.10-1.el5
python-qpid-qmf-0.10-9.el5
qpid-cpp-client-0.10-7.el5
qpid-cpp-client-devel-0.10-7.el5
qpid-cpp-client-devel-docs-0.10-7.el5
qpid-cpp-client-rdma-0.10-7.el5
qpid-cpp-client-ssl-0.10-7.el5
qpid-cpp-mrg-debuginfo-0.10-7.el5
qpid-cpp-server-0.10-7.el5
qpid-cpp-server-cluster-0.10-7.el5
qpid-cpp-server-devel-0.10-7.el5
qpid-cpp-server-rdma-0.10-7.el5
qpid-cpp-server-ssl-0.10-7.el5
qpid-cpp-server-store-0.10-7.el5
qpid-cpp-server-xml-0.10-7.el5
qpid-java-client-0.10-6.el5
qpid-java-common-0.10-6.el5
qpid-java-example-0.10-6.el5
qpid-qmf-0.10-9.el5
qpid-qmf-devel-0.10-9.el5
qpid-tools-0.10-5.el5
rh-qpid-cpp-tests-0.10-7.el5

-> VERIFIED
Comment 6 errata-xmlrpc 2011-06-23 11:44:57 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2011-0890.html

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