On 02/02/2014 09:24 PM, Fraser Adams wrote:
Hello all,
Over the last couple of weekends I decided to make a concerted effort to
try and get my head around the Qpid AMQP 1.0 support and to see if I can
replicate a whole bunch of use cases that I was able to support in AMQP
0.10.
I've attached a write up of my experiments along with some observations
that I made along the way. Be warned the attachment is *very long*.
Hopefully this will be useful to others who want to dip their toes in
the AMQP 1.0 waters. One of the issues that I was faced with was the
lack of solid and cohesive documentation for any of the AMQP 1.0
Address/Subscription information, hopefully the examples that I've
included in the write up can serve as a starting point.
I'd be really grateful if those who know this stuff better than me can
read through this and check if my observations are accurate, I think
that I might have discovered some quirks/defects/inconsistencies along
the way though I might just be misinterpreting things. It's probably
best to fight your way all the way through as it gets increasingly
adventurous.
Thanks for taking the time to write this up and share it with the list!
Feedback from users is what drives everything forward.
* AMQP 1.0 specific message properties
The x-amqp convention is indeed a qpid::messaging specific approach to
handling fields that do not have explicit accessors in the Message
class. It is described in the AMQP_1.0 readme. They should be set for
outgoing messages as of 0.24[1]. What version were you using?
As you note, the 'to' field can be set explicitly using the 'x-amqp-to'
property name. There is also a connection level option that controls
whether that should be automatically populated with the same address as
used in the target of the attach (set_to_on_send, which takes a boolean
value).
The 0-10 to 1.0 conversion currently maps the 0-10 message-transfer's
'destination' onto to the 'to' field. At the time I did it it seemed
logical enough, but I'm happy to remove that if it is confusing (as it
probably is).
* Text v. binary content
The translation from 0-10 messages to 1.0 equivalents only handles
content types for lists and maps at present. It should be improved to
check for text also. I've created a JIRA to track that[2].
* Subscription queues
I would say (loosely) that the subscription queue is part of the
terminus. I've added a sentence to the 1.0 readme describing how qpidd
constructs the subscription queue name.
I added the incoming and outgoing link entities as they seemed to be
useful when thinking in terms of the 1.0 model. The source and target
are as they appear in the attach received. Though there is no QMF
'object reference' to the subscription queue for an outgoing link from
an exchange, the naming policy for subscription queues does allow them
to be mapped to their corresponding outgoing links.
That said, I would agree that the situation around QMF and 1.0 links can
likely be improved upon, especially for people used to dealing with the
0-10 model. I've raised a JIRA to ensure that doesn't get lost[3].
* Reply-to
The qpid::messaging library doesn't particularly restrict the value of
the reply-to in the message itself[4].
If it can be interpreted as of the form <name>/<subject>, then the
address object returned will have both the name and subject set to the
respective substrings. Otherwise the name will contain the full reply-to.
If the application takes that address and uses it directly as an address
for creating a sender, the name is used as the source or target address
for the link and if a subject is specified it will be used to set a filter.
I believe a common usage will have reply-to simply contain a node name
(often for a temporary queue). That pattern, essentially the
client-server example, works against several brokers and also the
dispatch router[5]. It is also familiar from JMS.
However if some other specific scheme/format is used, the application
would responsible for interpreting the address and e.g. establishing
separate connections etc if that behaviour is desired.
* Shared subscriptions
The 'shared' subscription capability is described in the AMQP 1.0
readme. Note that it is a qpidd specific extension. At present the
subscription queue will be autodeleted unless you set the link to be
durable or reliable. Supporting an expiry policy of 'never' should be
possible as well. I'll update the test to note the convention around
queue name.
The auto-delete value specified on a topic will now be correctly used
for subscription queues created for that topic[6]. You can also specify
a lifetime-policy e.g. to delete only when not used *and* empty. This is
a nice option as it will be recreated if ever needed, but won't sit
around taking up resources if not.
* The 'create' option in qpid::messaging addresses
Using this option with an explicit node name results in non-standard
AMQP and is discouraged where it can be avoided. A better alternative is
to configure node policies. These are patterns that an attaching links
address are checked against if it doesn't resolve to any existing node.
If a matching pattern is found, the node will be auto-created with the
properties of that policy.
* Filters
In the case of the headers exchange, the key could be taken to be the
name of the filter, as the key is defined simply to be an identifier for
that exchange. However for other exchanges this would not be the case
(e.g. for topic, direct and even the qpidd specific xml exchanges, the
key affects matching and is therefore in my view logically part of the
filters value).
Note also that in AMQP 1.0 a message must match *all* the specified
filters, so you can't emulate OR with a set of different filters.
For the xml exchange the binding key is in fact an additional filtering
element that must match the subject. It is not just an identifier, as it
is in the case of the headers exchange. You can set the key using the
'subject' in the address, e.g. xml/weather.
Although AMQP itself does not place any restrictions on application
property names, the selector syntax for AMQP 1.0 is that of JMS
selectors[7], where as you noted, data-service is not a valid name. The
extension of the selector explicitly states "JMS header names should be
translated to amqp.<field_name> where <field_name> is the appropriate
AMQP 1.0 field named in the table above, with the hyphen replaced by an
underscore."
However we could probably look at ways to (optionally?) make this more
lenient. It certainly is also something that should be highlighted more
prominently in documentation somehow.
I believe the selector filters are supported by a number of brokers
outside Qpid (ActiveMQ, HornetQ, SwiftMQ). However the
legacy-amqp-filters are only supported by the two Qpid brokers at
present as far as I am aware.
[1] https://issues.apache.org/jira/browse/QPID-4707
[2] https://issues.apache.org/jira/browse/QPID-5536
[3] https://issues.apache.org/jira/browse/QPID-5537
[4] https://issues.apache.org/jira/browse/QPID-5168
[5] https://issues.apache.org/jira/browse/DISPATCH-1 and/or the
set_to_on_send connection option
[6] https://issues.apache.org/jira/browse/QPID-5469
[7] "The selector-filter uses the selector as defined by JMS."
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
