You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by m....@smartasking.com on 2012/05/02 19:42:08 UTC
Messaging Flow Design in Qpid
Hi All,
Thanks for all your help with the selector questions that I had last week. We are conducting more tests to see if Qpid is the solution for our architecture but we have some doubts...Our flow requires that exchanges subscribe to exchanges and queues in turn subscribe to multiple exchanges.
1) Is it possible to bind Exchanges to Exchanges? I have seen some posts giving an emphatic NO: ([http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html] http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html)
2) The x-binding syntax , that I have encountered, for binding a queue to multiple exchanges seems a little convoluted and the last time I asked you guys for help I discovered wonderful new simplified classes and methods :). Is the following example the best practice for creating multiple bindings?
x-bindings:[{queue:MYQUEUE,exchange:'FIRST_EXCHANGE',key: 'binding1', arguments:{'x-match':any,'a':'10'}}, { queue:MYQUEUE ,exchange:'SECOND_EXCHANGE',key: 'binding2', arguments: {'x-match':any,'a':'10'}}]
If so I would need to persist the "binding keys" (binding1, binding2) in order to remove the bindings later.
thanks for all your help,
Matthew
Re: Messaging Flow Design in Qpid
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 02/05/12 19:54, m.luchak@smartasking.com wrote:
> , but even so I would be wary of implementing features that are not supported.
That's an interesting discussion/debate :-) I think Gordon Sim and I
disagree on this one and he's more of the expert than I, however when we
last discussed this topic (bad pun!!) he conceded that it might be
useful to have a way to achieve intra (as opposed to inter) broker
routing. I believe this too, so my assertion is that until a more
appropriate mechanism is in place then a workaround using federation
isn't so very bad.
The question about "supported" is interesting in the sense that the
support of the qpid tools is variable, what I mean is that qpid-route
has been around for a long time and works well, but has its limitations
- for example federating using the headers exchange is limited to using
queue routes (dynamic routes I believe work from qpid 0.12) but static
routes don't - mainly because the command line options don't support it
rather than because it can't be done by the broker. Similarly IIRC when
you specify the exchange you use an exchange name, so (using the default
exchanges) you couldn't federate between say a fan-out exchange to a
headers exchange (though I'm pretty sure you can if you create your own
exchanges of the same name but different type).
This isn't a criticism of qpid-route BTW so please don't take as such,
it's merely a comment on the fact that it has grown relatively
organically but doesn't necessarily do all of the federation
possibilities that are available which may be useful, so I'm suggesting
that support is a relative term.
All of this stuff *is* actually supported however because "under the
hood" qpid-route used QMF methods to create links and bridges so if you
construct what you need directly using QMF the broker will actually do
it fine, which is why I believe my little hack of qpid-route is harmless
- if I'd written my own little QMF application to do this stuff it'd be
just another QMF application.
On your second question "Is there a simpler way to bind/unbind a queue
to multiple exchanges? " your bindings *looked* OK (by eyeball - I
haven't tried them). Unfortunately I'm not aware of a simpler/less
verbose way to describe the bindings you want :-(
In UML terms I think that bindings would look like an association class
between an exchange and a queue, so you you really have to specify both
the exchange and the queue.
You've got me thinking though, it might have been nice to have a syntax
such that one specifies an exchange & queue and a list of bindings
between them. I suspect that a common use case might be multiple
bindings between a given exchange and queue, so that way of describing
things would be slightly less verbose. It's just an idle musing, there's
probably a good reason that it's the way it is.
I use copy and paste reuse a lot when I'm creating addresses :-) It'd
take me ages to put one together from scratch. I wish the documentation
had some good headers exchange examples, I hate working things out from
BNF.......
Cheers,
Frase.
> That said, it seems a pretty harmless hack and taking care not to create a binding loop would actually be trivial in our particular case... so I guess I'll sleep on it ;)
>
> Any insight on my second question? Is there a simpler way to bind/unbind a queue to multiple exchanges?
>
>
> On 02/05/12 18:42, m.luchak@smartasking.com wrote:
>> Hi All,
>>
>> Thanks for all your help with the selector questions that I had last week. We are conducting more tests to see if Qpid is the solution for our architecture but we have some doubts...Our flow requires that exchanges subscribe to exchanges and queues in turn subscribe to multiple exchanges.
>>
>> 1) Is it possible to bind Exchanges to Exchanges? I have seen some posts giving an emphatic NO: ([http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html] http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html)
>>
>>
>> 2) The x-binding syntax , that I have encountered, for binding a queue to multiple exchanges seems a little convoluted and the last time I asked you guys for help I discovered wonderful new simplified classes and methods :). Is the following example the best practice for creating multiple bindings?
>>
>> x-bindings:[{queue:MYQUEUE,exchange:'FIRST_EXCHANGE',key: 'binding1', arguments:{'x-match':any,'a':'10'}}, { queue:MYQUEUE ,exchange:'SECOND_EXCHANGE',key: 'binding2', arguments: {'x-match':any,'a':'10'}}]
>>
>> If so I would need to persist the "binding keys" (binding1, binding2) in order to remove the bindings later.
>>
>>
>>
>> thanks for all your help,
>> Matthew
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Messaging Flow Design in Qpid
Posted by m....@smartasking.com.
Thanks Fraser,
We are using the C++ broker - selectors working client side is ok for us, but even so I would be wary of implementing features that are not supported. That said, it seems a pretty harmless hack and taking care not to create a binding loop would actually be trivial in our particular case... so I guess I'll sleep on it ;)
Any insight on my second question? Is there a simpler way to bind/unbind a queue to multiple exchanges?
thanks again,
Matthew
-----Original Message-----
From: "Fraser Adams" <fr...@blueyonder.co.uk>
Sent: Wednesday, May 2, 2012 2:36pm
To: users@qpid.apache.org
Subject: Re: Messaging Flow Design in Qpid
Hi Matthew,
I think that "technically" the answer is "no" however you could use
federation (with a little teeny bit of tweaking).
So it's possible to use qpid-route to federate between two brokers
however there's a line in qpid-route that throws an exception if you try
to do this -it moans about linking on the same host.
However...... the broker actually happily allows this.
I hacked the qpid-route addLink method thus...
def getLink(self):
links = self.agent.getObjects(_class="link")
for link in links:
if self.remote.match(link.host, link.port):
return link
return None
def addLink(self, remoteBroker, interbroker_mechanism=""):
self.remote = BrokerURL(remoteBroker)
#if self.local.match(self.remote.host, self.remote.port):
# raise Exception("Linking broker to itself is not permitted")
brokers = self.agent.getObjects(_class="broker")
broker = brokers[0]
link = self.getLink()
if link == None:
So literally just commented out the test for self.local.match and the
raise Exception and it works - one can federate from one exchange to
another on the same broker.
It's slightly controversial :-) but I wanted to see if it was possible.
You'd want to be careful to avoid circular routes etc.
But this approach might be what you're looking for unless someone can
come up with a better mechanism.
BTW federation only works with the C++ broker IIRC correctly so this
might be an issue for you I believe that you were planning on using the
Java broker (which gives you broker side message selectors) :-/
Frase
On 02/05/12 18:42, m.luchak@smartasking.com wrote:
> Hi All,
>
> Thanks for all your help with the selector questions that I had last week. We are conducting more tests to see if Qpid is the solution for our architecture but we have some doubts...Our flow requires that exchanges subscribe to exchanges and queues in turn subscribe to multiple exchanges.
>
> 1) Is it possible to bind Exchanges to Exchanges? I have seen some posts giving an emphatic NO: ([http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html] http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html)
>
>
> 2) The x-binding syntax , that I have encountered, for binding a queue to multiple exchanges seems a little convoluted and the last time I asked you guys for help I discovered wonderful new simplified classes and methods :). Is the following example the best practice for creating multiple bindings?
>
> x-bindings:[{queue:MYQUEUE,exchange:'FIRST_EXCHANGE',key: 'binding1', arguments:{'x-match':any,'a':'10'}}, { queue:MYQUEUE ,exchange:'SECOND_EXCHANGE',key: 'binding2', arguments: {'x-match':any,'a':'10'}}]
>
> If so I would need to persist the "binding keys" (binding1, binding2) in order to remove the bindings later.
>
>
>
> thanks for all your help,
> Matthew
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Messaging Flow Design in Qpid
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Matthew,
I think that "technically" the answer is "no" however you could use
federation (with a little teeny bit of tweaking).
So it's possible to use qpid-route to federate between two brokers
however there's a line in qpid-route that throws an exception if you try
to do this -it moans about linking on the same host.
However...... the broker actually happily allows this.
I hacked the qpid-route addLink method thus...
def getLink(self):
links = self.agent.getObjects(_class="link")
for link in links:
if self.remote.match(link.host, link.port):
return link
return None
def addLink(self, remoteBroker, interbroker_mechanism=""):
self.remote = BrokerURL(remoteBroker)
#if self.local.match(self.remote.host, self.remote.port):
# raise Exception("Linking broker to itself is not permitted")
brokers = self.agent.getObjects(_class="broker")
broker = brokers[0]
link = self.getLink()
if link == None:
So literally just commented out the test for self.local.match and the
raise Exception and it works - one can federate from one exchange to
another on the same broker.
It's slightly controversial :-) but I wanted to see if it was possible.
You'd want to be careful to avoid circular routes etc.
But this approach might be what you're looking for unless someone can
come up with a better mechanism.
BTW federation only works with the C++ broker IIRC correctly so this
might be an issue for you I believe that you were planning on using the
Java broker (which gives you broker side message selectors) :-/
Frase
On 02/05/12 18:42, m.luchak@smartasking.com wrote:
> Hi All,
>
> Thanks for all your help with the selector questions that I had last week. We are conducting more tests to see if Qpid is the solution for our architecture but we have some doubts...Our flow requires that exchanges subscribe to exchanges and queues in turn subscribe to multiple exchanges.
>
> 1) Is it possible to bind Exchanges to Exchanges? I have seen some posts giving an emphatic NO: ([http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html] http://qpid.2158936.n2.nabble.com/how-to-bind-exchange-to-exchange-like-bind-exchange-to-queue-in-the-same-broker-td6385448.html)
>
>
> 2) The x-binding syntax , that I have encountered, for binding a queue to multiple exchanges seems a little convoluted and the last time I asked you guys for help I discovered wonderful new simplified classes and methods :). Is the following example the best practice for creating multiple bindings?
>
> x-bindings:[{queue:MYQUEUE,exchange:'FIRST_EXCHANGE',key: 'binding1', arguments:{'x-match':any,'a':'10'}}, { queue:MYQUEUE ,exchange:'SECOND_EXCHANGE',key: 'binding2', arguments: {'x-match':any,'a':'10'}}]
>
> If so I would need to persist the "binding keys" (binding1, binding2) in order to remove the bindings later.
>
>
>
> thanks for all your help,
> Matthew
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org