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

Bug 509395

Summary:	The JMS Client does not default to the correct priority as specified in the spec
Product:	Red Hat Enterprise MRG	Reporter:	Rajith Attapattu <rattapat+nobody>
Component:	qpid-java	Assignee:	Rajith Attapattu <rattapat+nobody>
Status:	CLOSED ERRATA	QA Contact:	MRG Quality Engineering <mrgqe-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	1.1.2	CC:	cctrieloff, gsim
Target Milestone:	1.3
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	The JMS Client did not default to the correct priority as specified in the specification (0). This did not have any effect as the C++ broker does not yet support priority.With this update, the client now defaults to the correct priority (4). When the C++ broker implements priority, the messages sent through the JMS client will be handled according to the JMS specification.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-10-14 16:15:56 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:

Description Rajith Attapattu 2009-07-02 15:28:31 UTC

Description of problem:
The JMS Client does not default to the correct priority as specified in the spec.
Currently it defaults to 0, but should be 4

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

How reproducible:
Always

Steps to Reproduce:
Send a message as follows

TextMessage txtMsg = session.createTextMessage();
prod.send(txtMsg);
  
Actual results:
If you print the message on the receiving side it you could see the priority as zero

Expected results:
It should be 4.

Comment 1 Rajith Attapattu 2009-09-22 02:06:52 UTC

A fixed has been committed to rev 817478 on qpid trunk.
I have also added a simple check for the default message priority in an existing test in JMSPropertiesTest.

Comment 4 Rajith Attapattu 2010-10-07 17:42:31 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:
Cause: The JMS Client does not default to the correct priority as specified in the spec.

Consequence: This does not really have any effect as the C++ broker does not yet support priority.

Fix: The client now defaults to the correct priority (4).

Result: When the C++ broker implements priority, the messages sent through the JMS client will be handled according to the JMS spec.

Comment 5 Martin Prpič 2010-10-10 07:52:54 UTC

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1 @@
-Cause: The JMS Client does not default to the correct priority as specified in the spec.
+The JMS Client did not default to the correct priority as specified in the specification (0). This did not have any effect as the C++ broker does not yet support priority.With this update, the client now defaults to the correct priority (4). When the C++ broker implements priority, the messages sent through the JMS client will be handled according to the JMS specification.-
-Consequence: This does not really have any effect as the C++ broker does not yet support priority.
-
-Fix: The client now defaults to the correct priority (4).
-
-Result: When the C++ broker implements priority, the messages sent through the JMS client will be handled according to the JMS spec.

Comment 7 errata-xmlrpc 2010-10-14 16:15:56 UTC

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/RHSA-2010-0773.html