qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Review Request: provide means of configuring subscription queues for 'topics' over AMQP 1.0
Date Mon, 17 Jun 2013 11:37:31 GMT
On 06/16/2013 10:46 AM, Fraser Adams wrote:
> Hi Gordon,
> I'm afraid that I've *still* not got around to messing with proton/AMQP
> 1.0 (sorry, I've been tied in knots with various other things) so I
> won't be able to do the sort of review this really deserves.
>
> Firstly though thanks for doing this, I think that being able to provide
> this sort of configuration fixes a real limitation on queues
> "automagically" created under the hood (does this work with
> static/dynamic "exchange" routes too?).

This is AMQP 1.0 only. In 0-10 it is the client that actually create the 
queue (and at that point the broker can't tell what the queue is to be 
used for). In 1.0 the outgoing link is established from the exchange (or 
topic with this modification in use) and the subscription queue is under 
the full control of the broker which knows the context  in which it is 
to be used.

> I notice that you've also done some work with respect to the headers
> exchange x-binding stuff we discussed a little while back and similar
> for xquery/xml exchange.

Yes, the client still doesn't accept the 'x-bindings' option, but there 
is now a general purpose way of specifying 1.0 filters that covers the 
simple cases (i.e. a single binding from subscription queue to the 
exchange referenced as the node).

E.g.

my-xml-exchange; 
{link:{filter:{name:foo,descriptor:"apache.org:xquery-filter:string",value:"declare 
variable $colour external; $colour = 'red'"}}}

my-headers-exchange; 
{link:{filter:{name:bar,descriptor:"apache.org:legacy-amqp-headers-binding:map",value:{x-match:all,colour:red,

shape:square}}}}

As mentioned before it would in some cases be possible to auto-translate 
from x-bindings to filter syntax if there is sufficient benefit to 
justify the effort.

I should also modify the 0-10 client so that it also recognises this 
form of filter, meaning that one address could be used for either protocol.

> All of that is fantastic, so thanks very much. I don't suppose that
> you'd be able to post syntax examples for all of these to the user list
> (don't know if you've been able to update things like the Programming in
> Apache Qpid book?).

No, I haven't yet updated the book. I must do so.

> My headers bindings tend to follow a pattern similar
> to below:
>
>
> "testqueue; {create: receiver, node: {x-declare: {arguments:
> {'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
> [{exchange: 'amq.match', queue: 'testqueue', key: 'data1', arguments:
> {x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}"

That would now be handled in two steps. The first is a configuration 
step whereby a 'topic' is created referencing amq.match and specifying 
the desired 'policy' for subscription queues for that topic.

E.g. qpidt create topic amq.match.default exchange=amq.match 
qpid.policy_type=ring qpid.max_size=500000000

Then you would create your receiver using an address that referenced the 
topic created, and specifying the filter instead of the x-bindings. E.g.

amq.match.default; {link:{filter:{value:x-match:all,data-service: 
amqp-delivery, item-owner: 
fadams},name:data1,descriptor:"apache.org:legacy-amqp-headers-binding:map"}}}

All subscriptions from this new topic would use the default queue 
configuration specified for the topic.

It was really this approach - define subscription queue config via 
configuration rather than directly through the address used by receivers 
- that I wanted your thoughts on (more than on the actual code). Would 
this be an acceptable/useful solution? (Note, you can create different 
topics referencing the same exchange if you want to specify different 
policies for different types of use case).

> TBH it took a bit of trial and error to figure out the headers binding
> syntax at all (sometimes still seems a bit of a black art) so perhaps
> the most constructive review comment that I can come up with is that
> plenty of example address strings and other config. for various use
> cases (including the new shared topic subscription if it needs any
> special syntax) would be *really* useful.
>
> Thanks again for this - and sorry again I can't yet do it justice.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message