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

Bug 1268872

Summary: [Selectors] JMSExpiration can't be queried on exact values properly
Product: Red Hat Enterprise MRG Reporter: Michal Toth <mtoth>
Component: qpid-cppAssignee: messaging-bugs <messaging-bugs>
Status: CLOSED UPSTREAM QA Contact: Messaging QE <messaging-qe-bugs>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.2CC: gsim, jross
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:48:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michal Toth 2015-10-05 13:42:19 UTC
Error has been found while querying for JMSExpiration message header property.

Following text was taken from Bug 1254944, Comment 17: https://bugzilla.redhat.com/show_bug.cgi?id=1254944#c17 

"I would like to add, that expiration time is affected as well. (Seems like a different issue to Bug 1268257)"

Send a message
org.apache.qpid.example.qc3_spout  --log-msgs dict --broker guest/guest.75.219:5672 --connection-options "{  sasl_mechanisms : 'PLAIN', protocol : 'amqp1.0' }" --count 1 --content "KEKcL0zHkG" --ttl 100000  "test_jms_header_jmsexpiration"
{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444027015850, 'timestamp': 1444026915850, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': 'e26a424b-f07b-4487-a5a7-754297451159:0'}, 'content': 'KEKcL0zHkG'}

Browse the queue (8:40:32 in logs)
$ org.apache.qpid.example.qc3_drain  --timeout 2 --log-msgs dict --broker guest/guest.75.219:5672 --connection-options "{  sasl_mechanisms : 'PLAIN', protocol : 'amqp1.0' }" --msg-selector "JMSExpiration>1444026908172" --recv-browse true  'test_jms_header_jmsexpiration'
{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444027015850, 'timestamp': 1444026915850, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': 'e26a424b-f07b-4487-a5a7-754297451159:0'}, 'content': 'KEKcL0zHkG'}

Obtain the message (did not work)
$ org.apache.qpid.example.qc3_drain  --timeout 2 --log-msgs dict --broker guest/guest.75.219:5672 --connection-options "{  sasl_mechanisms : 'PLAIN', protocol : 'amqp1.0' }" --msg-selector "JMSExpiration=1444027015850" --recv-browse true  'test_jms_header_jmsexpiration'
{}


Here are the selector logs.
2015-10-05 08:40:32 [Broker] debug Selector parsed[JMSExpiration>1444026908172] into: (I:JMSExpiration>EXACT:1444026908172)
2015-10-05 08:40:32 [Broker] debug Selector lookup JMS identifier: JMSExpiration treated as alias for absolute_expiry_time
2015-10-05 08:40:32 [Broker] debug Selector identifier: JMSExpiration->EXACT:1444027316283

2015-10-05 08:40:50 [Broker] debug Selector parsed[JMSExpiration=1444027015850] into: (I:JMSExpiration=EXACT:1444027015850)
2015-10-05 08:40:50 [Broker] debug Selector lookup JMS identifier: JMSExpiration treated as alias for absolute_expiry_time
2015-10-05 08:40:50 [Broker] debug Selector identifier: JMSExpiration->EXACT:1444027316283

Also comparing on <,> worked (but it seems like the ">" is treated like ">=".

{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444027539151, 'timestamp': 1444027439151, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': '8cc57602-20c6-4c74-a695-d72873ee5ce3:0'}, 'content': 'older msg'}
{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444027963737, 'timestamp': 1444027463737, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': '6da2254e-5fa9-489d-a190-05f0d5df8805:0'}, 'content': 'shorter ttl'}
{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444029452765, 'timestamp': 1444027452765, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': '69acbdb3-37a5-4722-ae29-f98c975366e8:0'}, 'content': 'longer ttl'}


org.apache.qpid.example.qc3_drain  --timeout 2 --log-msgs dict --broker guest/guest.75.219:5672 --connection-options "{  sasl_mechanisms : 'PLAIN', protocol : 'amqp1.0' }" --msg-selector "JMSExpiration > 1444029452765" --recv-browse true  'test_jms_header_jmsexpiration'
{'redelivered': False, 'reply_to': None, 'id': None, 'correlation_id': None, 'priority': 4, 'durable': True, 'destination': 'test_jms_header_jmsexpiration', 'type': None, 'expiration': 1444029452765, 'timestamp': 1444027452765, 'properties': {'JMSXDeliveryCount': 1, 'spout_id': '69acbdb3-37a5-4722-ae29-f98c975366e8:0'}, 'content': 'longer ttl'}

Not that it is a big issue, as JMSExpiration works, but it worths to be mentioned. 
I would give it same priority as Bug 1268257.
"

Version-Release number of selected component (if applicable):
qpid-cpp-server-0.34-5.el6.x86_64
qpid-jms-client-0.5.0-2.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Send a message with given expiration time (ttl)
2. Query broker with selector for exact selector value (=) (Browse queue to get exact expiration value).

Actual results:
No message is returned.

Expected results:
Message with exactly matching expiration value should be obtained.

Additional info:
It seems like the ">" is treated like ">=".

Comment 1 Gordon Sim 2015-10-05 14:44:28 UTC
Again, the issue here is a legacy from how expiration was specified for 0-10, where it is computed from the ttl. Refactoring to allow different approaches for the two different protocols would certainly be possible if/when desired.

Comment 3 Red Hat Bugzilla 2025-02-10 03:48:16 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.