non "exclusivity" leads to behaviour that is rather counterintuitive

[fadams <fr...@blueyonder.co.uk>]

I've been playing with the Headers Exchange and set up a producer client to
send messages to the exchange. I have two properties DataService & ItemOwner
- for my test I sent some messages with ItemOwner=fadams and some with
ItemOwner=jdadams

How I'd intend to use this would be to have two separate consumers one
"subscribing" based on ItemOwner=fadams and the other based on
ItemOwner=jdadams

My consumer client is a basic JMS client and I set up an address in JNDI
along the lines of the following:

destination.subscribedAddress1 = Q1; {create: receiver, node: {x-bindings:
[{exchange: 'amq.match', queue: 'Q1', key: 'data1', arguments: {x-match:
all, DataService: PriceLog, ItemOwner: fadams}}]}}

This worked fine so I was quite pleased - especially as the address syntax
is just a bit cryptic and there's no obvious documentation for bindings to
the HeadersExchange so I had to wing it a bit.

However one gotcha I stumbled across was when I changed my address to see
what happens with the other half of the messages I'd sent - so I changed the
address to

destination.subscribedAddress1 = Q1; {create: receiver, node: {x-bindings:
[{exchange: 'amq.match', queue: 'Q1', key: 'data1', arguments: {x-match:
all, DataService: PriceLog, ItemOwner: jdadams}}]}}

What I thought would happen was that my consumer client would start to
receive messages labelled with ItemOwner=jdadams however what actually
happened was that I got all the messages sent by the producer because the
new address added the new binding rather than replacing it - despite the key
being the same.


In my application I was pretty keen to work to a "self service" model where
consumers subscribe to data they want based upon it's "signature" in the
headers. My guess is that consumers could quite easily get things wrong as
they experiment with the headers they want to match and I'd guess that
"incremental" bindings are counterintuitive and most clients would "assume"
that changing the address would replace the binding.

It's likely to be really hard to figure out where the screw up has occurred
- multiple keys in the binding as displayed by qpid-config is probably the
biggest hint, but would be easy to miss in a large system with lots of
queues and bindings.

This feels like an accident waiting to happen - have I missed something? Is
there a good way round this or do I just have to tell consumers to be
careful and explicitly delete bindings before "changing" them - of course I
can then guarantee "Murphy's Law" will kick in.....

As an aside does anyone know of a good tutorial on the HeadersExchange and
addresses - the BNF in the documentation is all very well, but some good
examples would make it an awful lot more obvious.
MTIA
fadams








--
View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/non-exclusivity-leads-to-behaviour-that-is-rather-counterintuitive-tp6159008p6159008.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