qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: How to set a binding on a receiver
Date Fri, 07 Oct 2011 12:43:06 GMT
On 10/07/2011 10:48 AM, Fraser Adams wrote:
> Gordon Sim wrote:
>> On 10/05/2011 09:32 AM, Luca Martini wrote:
>>> However, I would like to add a key binding to an already created
>>> Receiver.
>>> Is it possible?
>>
>> Not directly through the messaging API, no.
>>
> Is that statement 100% correct Gordon?

I guess it depends on how you interpret 'directly'. What I meant was 
that the API does not support modifying the bindings or other address 
properties for a receiver once it is created.

The approach you describe adds bindings when creating new receivers, 
using the auto-create feature. That approach can be used to alter the 
messages a previously created receiver receives, but I view it more as a 
side-effect.

You are quite correct though in pointing out another option.

> With the headers exchange at
> least I've found that if I were to specify an address that creates a
> queue and add a binding say:
>
> testqueue; {create: receiver, node: {x-declare: {arguments:
> {'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
> [{exchange: 'amq.match', queue: 'testqueue', key: 'data1', arguments:
> {x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}
>
> If I change the arguments thus:
>
> testqueue; {create: receiver, node: {x-declare: {arguments:
> {'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
> [{exchange: 'amq.match', queue: 'testqueue', key: 'data2', arguments:
> {x-match: all, data-service: amqp-delivery, item-owner: jdadams}}]}}
>
> I end up with two bindings to testqueue. It also does this if I don't
> change key, but in this case the broker generates a warning (rightly).
> IIRC the 0.8 broker didn't warn about this.
>
> TBH I sometimes wonder to myself whether this behaviour is more of a bug
> than a feature :-) as it leads to counterintuitive behaviour when people
> are experimenting with bindings, as they tend to assume that just
> changing the binding is OK - Imagine their surprise when they find out
> they've got ten bindings instead of just the most recent :-D I've done
> it myself and I know about the behaviour :-(
>
> Sometimes it has proved useful though. When I discovered the
> qpid::messaging AddressParser problem where it was adding bindings with
> binary values before I came up with the "utf8EncodeAddress()" fix I
> posted last week my dirty workaround was to connect but not consume from
> a Java client with the same address so the queue ended up with two
> bindings that "looked" the same.
>
> It might be different with the topic exchange though.
>>
>>> My concern is
>>> that, with hundreds (or thousands) of subscriptions, the broker could
>>> become a bottleneck for our system. I know I'm being rather vague, but
>>> if you could give me some suggestions or remarks, it would be very
>>> appreciated.
>>
>> I suspect it depends a lot on the details of the bindings, exchange
>> and matching patterns. If each message matches only one binding, I
>> suspect that there is no great benefit to using the same queue in each
>> binding. However if the bindings overlap a lot then this may change.
>>
>>
> I suspect that if there are hundreds or thousands of bindings there
> might actually be a disbenefit using the same queue in each binding. I'm
> still trying to get under the skin of the MRG whitepaper, but IIRC that
> was talking of using multiple queues on a multi-core box. I don't know
> how qpidd threading actually works, though with my box at home I've
> never been able to drive it hard enough to show more than 100% CPU. I'm
> assuming that with qpid-perftest, multiple boxes and a decent network
> one could utilise all the cores.
>
> That said I do wonder about the statement "the broker could become a
> bottleneck for our system" I'd be pretty impressed to see that, its far
> more likely to hit network saturation way before the broker has any issues.
>
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message