Red Hat Bugzilla – Bug 988297
qpid::messaging::Message API doesn't permit sending non-string message IDs
Last modified: 2015-11-15 20:17:41 EST
Description of problem:
qpid::messaging::Message API does not fully model AMQP 1.0 Message enhancements.
qpid::messaging resp. qpid.messaging API was built with AMQP 0-10 in mind.
AMQP 1.0 come with some changes in Message model:
message-id may be in various types:
<field name="message-id" type="*" requires="message-id"/>
<type name="message-id-ulong" class="restricted" source="ulong" provides="message-id"/>
<type name="message-id-uuid" class="restricted" source="uuid" provides="message-id"/>
<type name="message-id-binary" class="restricted" source="binary" provides="message-id"/>
<type name="message-id-string" class="restricted" source="string" provides="message-id"/>
See  chapters 3.2.4, 3.2.11 - 3.2.14.
Moreover there were added following message properties:
<field name="to" type="*" requires="address"/>
<field name="subject" type="string"/>
<field name="group-id" type="string"/>
<field name="group-sequence" type="sequence-no"/>
<field name="reply-to-group-id" type="string"/>
( <field name="absolute-expiry-time" type="timestamp"/> matches probably to expriration in amqp 0-10)
I was comparing  3.2.4 Properties vs.  'Domain: message.message-properties'
The qpid proton APIs are at the moment reflecting  3.2.4 table well except field 'to' which is there not available as well.
Is there plan to extend qpid::messaging / qpid.messaging to support also AMQP 1.0 specific fields? If not it is necessary to guide users using documentation to use qpid proton API.
Feel free to reassign to docs based on your judgement.
 pylint qpid.messaging.Message
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. check  getMessageId() method > std::string & getMessageId () const
2. AMQP 1.0 says ( chapters 3.2.4) it may be string
qpid::messaging does not fully support AMQP 1.0 message
qpid::messaging to fully support AMQP 1.0 message or document there are some gaps.
Gordon, please assess.
Regarding the possibility of different message-id types, the code at present should map all 1.0 allowed types onto a string for incoming messages. If the id is a UUID this will be the stringified representation of the UUID; if the id is a long, this will be a string representing that number (e.g. "1000346"), if it is a binary or a string then it will hold the actual bytes as sent. However at present there is no way to send an id as anything other than a string. That should really be fixed.
Regarding the added message properties, the AMQP 1.0 specific fields can be accessed as pseudo-properties using the key format x-amqp-<field-name>, where <field-name> is the name of the field in the AMQP 1.0 specification. The keys currently in use are: x-amqp-first-acquirer and x-amqp-delivery-count for the header section, and x-amqp-to, x-amqp-absolute-expiry-time, x-amqp-creation-time, x-amqp-group-id, x-amqp-qroup-sequence and
x-amqp-reply-to-group-id for the properties section. Of course explicit accessors could also be added for these, but that would be more for convenience rather than absolute necessity.
"However at present there is no way to send an id as anything other than a string. That should really be fixed."
I'm taking this to be the content of this issue as of now.
Yes, that is the issue. My view is it isn't super urgent (correct me if that is wrong). Its very much a case of anticipating corner cases. I've added https://issues.apache.org/jira/browse/QPID-5180 upstream to track the issue.