Bug 1264000 - Docs: MPR should describe all JMS headers mappings to AMQP 1.0 for selectors
Docs: MPR should describe all JMS headers mappings to AMQP 1.0 for selectors
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Messaging_Programming_Reference (Show other bugs)
Unspecified Unspecified
medium Severity unspecified
: ---
: ---
Assigned To: Scott Mumford
Michal Toth
Depends On:
Blocks: 1215806
  Show dependency treegraph
Reported: 2015-09-17 05:43 EDT by Michal Toth
Modified: 2015-10-13 09:01 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-13 09:01:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Toth 2015-09-17 05:43:32 EDT
Description of problem:
Currently MPR document contains only 3 JMS header names (mapped to AMQP 1.0) in "Table 20.15. Mapping JMS Headers to AMQP fields".
Similar mapping to AMQP-0.10 can be found in "Table 20.3. Java JMS Mapping to AMQP 0-10 Message Properties". (this one is complete)

So I think, we should also fully document mapping between JMS <-> AMQP 1.0 in table 20.15 or just add note,
that this mapping works in both AMQP 0.10 and 1.0 versions.

Personally, I have found to be the most tricky to use "JMSDeliveryMode" how to use NON_PERSISTENT and PERSISTENT options were not clear on first thought.

Actual results:
Mapping between JMS and AMQP 1.0 is unfinished.
Currently only "delivery_mode", "priority" and "redelivered" are documented.

Expected results:
All JMS header names are documented in the table.

Additional info:
See Bug 1254944 for more information.
Comment 1 Scott Mumford 2015-09-21 20:52:12 EDT
Hi Michal,

I notice that two of the header names you've listed don't appear in either table: JMSDestination and JMSTimestamp.

Can you point me to where I'd get the AMQP headers that map to those?

Once I've got that info I'll add it to the contents of the second table (20.3), then copy that table into the first location (table 20.15) and replace table 20.3 with a link back to the first (it makes no sense to duplicate the content like this).

I'll also add a note that these mappings are consistent with both AMQP 0.10 and 1.0.

If I've misunderstood anything, please let me know.
Comment 2 Michal Toth 2015-09-22 02:30:33 EDT

 I have added affecting BZ to "See also" field here which points to original Bug 1254944. For documentation, you should ask developers for development notes on what has been changed, how to document it etc, which points to Gordon (setting need info on him here). :)

As from what was changed, if I look at his patch to broker (which I should not as QA :) ), I see, that here "https://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/broker/Selector.cpp?r1=1698426&r2=1698425&pathrev=1698426" is done "probably all" the mapping. 

Please wait for Gordon's approval about this. ;)

On the updates of doc tables, looks like it will work well.
I hope it answers your questions.
 Thank you Scott.
Comment 3 Gordon Sim 2015-09-22 04:29:54 EDT
The translation performed by qpidd is as follows:

JMSType          -> subject field in properties
JMSCorrelationID -> correlation-id field in properties
JMSMessageID     -> message-id field in properties
JMSDeliveryMode  -> durable ? "PERSISTENT" : "NON_PERSISTENT"  (computed from field in header)
JMSRedelivered   -> delivery-count > 0 (computed from field in header)
JMSPriority      -> priority field in header
JMSDestination   -> to field in properties
JMSReplyTo       -> reply-to field in properties
JMSTimestamp     -> creation-time field in properties
JMSExpiration    -> absolute-expiry-time field in properties

However from the JMS spec: "Message header field references are restricted to JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and
JMSType." So when using JMS, only these fields would strictly be valid in a selector. (The broker doesn't enforce this. the client might).
Comment 5 Michal Toth 2015-09-25 04:09:24 EDT
Changes made in MPR looks good to me.
I am marking it as verified.
Thank you

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