From users-return-9854-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Mon Feb 3 15:37:04 2014 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C41F010D02 for ; Mon, 3 Feb 2014 15:37:04 +0000 (UTC) Received: (qmail 7943 invoked by uid 500); 3 Feb 2014 15:37:04 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 7507 invoked by uid 500); 3 Feb 2014 15:36:50 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 7483 invoked by uid 99); 3 Feb 2014 15:36:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Feb 2014 15:36:46 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Feb 2014 15:36:39 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s13FaG1r002393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Feb 2014 10:36:16 -0500 Received: from [10.36.116.63] (ovpn-116-63.ams2.redhat.com [10.36.116.63]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s13Fa5Hs015400 for ; Mon, 3 Feb 2014 10:36:06 -0500 Message-ID: <52EFB7EA.7040509@redhat.com> Date: Mon, 03 Feb 2014 15:38:18 +0000 From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Matt Parsons (USA), Charlie Peters (USA), Paul Hickey (Ireland) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: A write up of some AMQP 1.0 Experiments References: <52EEB7A8.3040707@blueyonder.co.uk> In-Reply-To: <52EEB7A8.3040707@blueyonder.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Virus-Checked: Checked by ClamAV on apache.org 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 /, 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. where 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