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:[email protected]
