Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 760636

Summary: Message Group query method should include message timestamp if present.
Product: Red Hat Enterprise MRG Reporter: Ken Giusti <kgiusti>
Component: qpid-cppAssignee: Ken Giusti <kgiusti>
Status: CLOSED ERRATA QA Contact: Leonid Zhaldybin <lzhaldyb>
Severity: low Docs Contact:
Priority: medium    
Version: DevelopmentCC: esammons, iboverma, jross, lzhaldyb, pematous
Target Milestone: 2.1.2Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-cpp-mrg-0.14-3.el5 Doc Type: Enhancement
Doc Text:
The QMF Broker method "query" will return extra detail for a message group queue's internal state. For example, assume a message group queue called "msg-group-q" exists on a broker. The following python code would retrieve this extra state: # verify the query method call's group information rc = broker.query("queue", "msg-group-q") assert rc.status == 0 results = rc.outArgs['results'] assert 'qpid.message_group_queue' in results q_info = results['qpid.message_group_queue'] The data returned in 'q_info' above is a map data-type with the following layout: { "qpid.message_group_queue": { "group_header_key" : "<KEY>", "group_state" : [ { "group_id" : "<name>", "msg_count" : <int>, "timestamp" : <absTime>, "consumer" : <consumer name> }, {...} // one for each known group ] } } If the broker has been configured to timestamp messages on arrival, the "timestamp" field will contain the timestamp of the oldest message of the group. A value of zero would indicate that the oldest message has been acquired but not yet dequeued.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-30 17:53:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 734115, 751883    
Bug Blocks: 783492    

Description Ken Giusti 2011-12-06 16:54:17 UTC
Description of problem:

The Query method as implemented for message group queues should return the timestamp of the oldest message of each group - if the message contains an 0.10 timestamp.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ken Giusti 2011-12-06 16:56:37 UTC
The "fix" is available upstream at the following revision:

http://svn.apache.org/viewvc?view=revision&revision=1199914

Comment 5 Leonid Zhaldybin 2012-01-12 10:19:44 UTC
Tested using the following packages:

RHEL5.7
python-qpid-0.14-1.el5
python-qpid-qmf-0.14-2.el5
qpid-cpp-client-0.14-3.el5
qpid-cpp-client-devel-0.14-3.el5
qpid-cpp-client-devel-docs-0.14-3.el5
qpid-cpp-client-rdma-0.14-3.el5
qpid-cpp-client-ssl-0.14-3.el5
qpid-cpp-debuginfo-0.12-6.el5
qpid-cpp-server-0.14-3.el5
qpid-cpp-server-cluster-0.14-3.el5
qpid-cpp-server-devel-0.14-3.el5
qpid-cpp-server-rdma-0.14-3.el5
qpid-cpp-server-ssl-0.14-3.el5
qpid-cpp-server-store-0.14-3.el5
qpid-java-client-0.14-1.el5
qpid-java-common-0.14-1.el5
qpid-java-example-0.14-1.el5
qpid-qmf-0.14-2.el5
qpid-qmf-debuginfo-0.14-2.el5
qpid-qmf-devel-0.14-2.el5
qpid-tools-0.14-1.el5

RHEL6.2
python-qpid-0.14-1.el6
python-qpid-qmf-0.14-3.el6
qpid-cpp-client-0.14-1.el6
qpid-cpp-client-devel-0.14-1.el6
qpid-cpp-client-devel-docs-0.14-1.el6
qpid-cpp-client-rdma-0.14-1.el6
qpid-cpp-client-ssl-0.14-1.el6
qpid-cpp-debuginfo-0.14-1.el6
qpid-cpp-server-0.14-1.el6
qpid-cpp-server-cluster-0.14-1.el6
qpid-cpp-server-devel-0.14-1.el6
qpid-cpp-server-rdma-0.14-1.el6
qpid-cpp-server-ssl-0.14-1.el6
qpid-cpp-server-store-0.14-1.el6
qpid-cpp-server-xml-0.14-1.el6
qpid-qmf-0.14-3.el6
qpid-qmf-devel-0.14-3.el6
qpid-tools-0.14-1.el6

-> VERIFIED

Comment 6 Petr Matousek 2012-01-17 15:07:09 UTC
This issue has been implemented.

One related issue was found: if the head message is acquired but not yet
acknowledged/rejected by a consumer, the query method returns zero in the value
of the timestamp. see Bug 781496.

Verified on RHEL5.7 and RHEL6.2, architectures: x86_64, i686 

packages installed:
qpid-cpp-mrg-0.14-3.el5
qpid-qmf-0.14-2.el5
qpid-cpp-0.14-1.el6
qpid-qmf-0.14-3.el6

-> VERIFIED

Comment 7 Ken Giusti 2012-03-13 17:17:59 UTC
    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:
The QMF Broker method "query" will return extra detail for a message group queue's internal state.

For example, assume a message group queue called "msg-group-q" exists on a broker.  The following python code would retrieve this extra state:

        # verify the query method call's group information
        rc = broker.query("queue", "msg-group-q")
        assert rc.status == 0
        results = rc.outArgs['results']
        assert 'qpid.message_group_queue' in results
        q_info = results['qpid.message_group_queue']

The data returned in 'q_info' above is a map data-type with the following layout:

       { "qpid.message_group_queue":
            { "group_header_key" : "<KEY>",
              "group_state" :
                   [ { "group_id"  : "<name>",
                       "msg_count" : <int>,
                       "timestamp" : <absTime>,
                       "consumer"  : <consumer name> },
                     {...} // one for each known group
                   ]
            }
        }

If the broker has been configured to timestamp messages on arrival, the "timestamp" field will contain the timestamp of the oldest message of the group.  A value of zero would indicate that the oldest message has been acquired but not yet dequeued.

Comment 8 errata-xmlrpc 2012-04-30 17:53:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0529.html