You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by fadams <fr...@blueyonder.co.uk> on 2011/09/04 16:04:51 UTC
"not" values in the headers exchange
Hi,
I'm curious if there is an ability to do "not" selectors via the headers
exchange.
so for example I might have two headers lets say type and subtype and it
might be nice to select messages of type=fruit and subttype != peach so I
can select all fruit except peaches. That's clearly a lot less convoluted
(and error prone) than having an x-match all containing all the positive
matches (and also if I add a new fruit I'd have to update the binding, but
with the not selector I wouldn't).
If it's not possible with the headers exchange could someone suggest some
clever trickery to do that type of thing.
Cheers,
Frase
--
View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/not-values-in-the-headers-exchange-tp6758416p6758416.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: "not" values in the headers exchange
Posted by Gordon Sim <gs...@redhat.com>.
On 09/09/2011 01:39 PM, Fraser Adams wrote:
> Thanks Gordon.
> Are there any plans to extend the features of the headers exchange? The
> "and" pattern of headers is pretty good for most cases I'm interested
> in, but there's always the exception :-)
>
> I was aware of the XML exchange but I haven't looked hard at it as a)
> I'm worried about performance implications and b) it adds more
> complexity to subscription patterns and c) the standard tools work well
> for topic exchange but need tweaking to record info for the headers
> exchange and will need more tweaking for XML exchange
>
> Are you aware of any benchmarks that cover the relative performance of
> topic vs headers vs XML exchanges. It was my understanding that
> wildcards in topics start to get more expensive as the subject depth
> increases (am I correct in thinking that regexes are employed?) that
> said I quickly skimmed the headers exchange code and looks like there's
> some linear searching going on so I imagine with lots of headers and
> lots of x-match attributes it could get expensive.
>
> Another concern I've got is that we've got producers writing to the
> headers exchange. I guess that's probably not a big issue as we're using
> a federated topology and it's in the "right hand" brokers where the real
> matching takes place so I guess that we can use a queue route and link
> the source to whatever exchange we need on the destination broker and I
> guess that we could load share onto multiple brokers.
>
> I'd appreciate thoughts on relative performance of exchange types etc.
I haven't really tried it out. A lot depends on the exact patterns of
matching used (as much as the types of exchanges themselves).
The XML exchange uses the binding key as a first match, and only
evaluates the xqueries where the binding key matches the routing key for
a message. That may allow you to control the complexity of matching to a
degree.
The headers exchange has to potentially check *all* bindings as the
binding key there is used only for identifying the binding in the event
of unbind etc.
I think if you start extending the headers exchange you will quickly
reach the point where you need a query syntax to express the matching
logic. I do think having routing that uses the sort of syntax provided
by JMS selectors (i. subset of SQL91) would be useful. Optimising
implementations for particular patterns would of course be interesting.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: "not" values in the headers exchange
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Thanks Gordon.
Are there any plans to extend the features of the headers exchange? The
"and" pattern of headers is pretty good for most cases I'm interested
in, but there's always the exception :-)
I was aware of the XML exchange but I haven't looked hard at it as a)
I'm worried about performance implications and b) it adds more
complexity to subscription patterns and c) the standard tools work well
for topic exchange but need tweaking to record info for the headers
exchange and will need more tweaking for XML exchange
Are you aware of any benchmarks that cover the relative performance of
topic vs headers vs XML exchanges. It was my understanding that
wildcards in topics start to get more expensive as the subject depth
increases (am I correct in thinking that regexes are employed?) that
said I quickly skimmed the headers exchange code and looks like there's
some linear searching going on so I imagine with lots of headers and
lots of x-match attributes it could get expensive.
Another concern I've got is that we've got producers writing to the
headers exchange. I guess that's probably not a big issue as we're using
a federated topology and it's in the "right hand" brokers where the real
matching takes place so I guess that we can use a queue route and link
the source to whatever exchange we need on the destination broker and I
guess that we could load share onto multiple brokers.
I'd appreciate thoughts on relative performance of exchange types etc.
Cheers,
Frase
Gordon Sim wrote:
> On 09/04/2011 03:04 PM, fadams wrote:
>> Hi,
>> I'm curious if there is an ability to do "not" selectors via the headers
>> exchange.
>
> No, there isn't.
>
> You could use the xml exchange; its a non-standard exchange that
> supports x-query based bindings that allow more sophisticated matching
> logic on application defined properties. It doesn't actually require
> you to send xml content.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: "not" values in the headers exchange
Posted by Gordon Sim <gs...@redhat.com>.
On 09/04/2011 03:04 PM, fadams wrote:
> Hi,
> I'm curious if there is an ability to do "not" selectors via the headers
> exchange.
No, there isn't.
> so for example I might have two headers lets say type and subtype and it
> might be nice to select messages of type=fruit and subttype != peach so I
> can select all fruit except peaches. That's clearly a lot less convoluted
> (and error prone) than having an x-match all containing all the positive
> matches (and also if I add a new fruit I'd have to update the binding, but
> with the not selector I wouldn't).
>
> If it's not possible with the headers exchange could someone suggest some
> clever trickery to do that type of thing.
You could use the xml exchange; its a non-standard exchange that
supports x-query based bindings that allow more sophisticated matching
logic on application defined properties. It doesn't actually require you
to send xml content.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org