Bug 781496 – Incorrect timestamp returned by query method call

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 781496 - Incorrect timestamp returned by query method call

Summary:	Incorrect timestamp returned by query method call

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise MRG
Classification:	Red Hat
Component:	qpid-qmf (Show other bugs)
Sub Component:
Version:	Development
Hardware:	Unspecified Unspecified

Priority	low Severity medium
Target Milestone:	2.3
Target Release:	---
Assigned To:	Ken Giusti
QA Contact:	Petr Matousek
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:	734115
Blocks:
	Show dependency tree / graph

Reported:	2012-01-13 10:45 EST by Petr Matousek
Modified:	2013-03-06 13:54 EST (History)
CC List:	3 users (show)

See Also:
Fixed In Version:	qpid-qmf-0.18-5, qpid-cpp-*-0.18-6
Doc Type:	Bug Fix
Doc Text:	Cause: Messages were removed from the Queue when acquired by a client. Consequence: When querying for the message timestamp, acquired messages were no longer available and the timestamp could not be retrieved. A timestamp of zero was returned. Fix: Acquired messages now remain on the Queue, and are available for querying the timestamp. Result: A valid timestamp is returned for messages that have been acquired.
Story Points:	---
Clone Of:
Environment:
Last Closed:	2013-03-06 13:54:26 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
test reproducer (2.40 KB, application/x-python) 2012-01-13 10:48 EST, Petr Matousek	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2013:0561	normal	SHIPPED_LIVE	Moderate: Red Hat Enterprise MRG Messaging 2.3 security update	2013-03-06 18:48:13 EST

Groups: None (edit)

Description Petr Matousek 2012-01-13 10:45:34 EST

Description of problem:

The QMF Query method returns the timestamp of the oldest message for each message group if the timestamping is enabled on the broker (see Bug 760636) - this works fine. But 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.

I'm not sure if the result shall contain the timestamp of the acquired message or the timestamp of the next message, but it shall definitely not be equal to zero.

Version-Release number of selected component (if applicable):
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-ssl-0.14-3.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-ssl-0.14-3.el5
qpid-cpp-server-store-0.14-3.el5
qpid-cpp-server-xml-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-devel-0.14-2.el5
qpid-tests-0.14-1.el5
qpid-tools-0.14-1.el5

How reproducible:
100%

Steps to Reproduce:
1. enable timestamping on the broker
2. create a message groups queue
3. send several messages on the queue
4. acquire a message, but do not acknowledge/reject yet
5. call the query method
6. the timestamp in the result of the query method call is zero

Actual results:
The result of the query method call returns zero if the message is acquired but not yet acknowledged/rejected

Expected results:
Relevant timestamp is returned by the query method call

Comment 1 Petr Matousek 2012-01-13 10:48:44 EST

Created attachment 555092 [details]
test reproducer

Comment 7 Petr Matousek 2012-11-12 10:13:46 EST

This issue has been fixed.

Verified on rhel5 and rhel6 (both i386,x86_64)

packages used for testing:
qpid-qmf-0.18-6
qpid-cpp-*-0.18-7

-> VERIFIED

Comment 9 errata-xmlrpc 2013-03-06 13:54:26 EST

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-2013-0561.html

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