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