qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: A write up of some AMQP 1.0 Experiments
Date Mon, 03 Feb 2014 15:38:18 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message