On 02/26/2010 03:09 PM, Alan Conway wrote:
On 02/26/2010 09:47 AM, Gordon Sim wrote:
On 02/26/2010 02:29 PM, Alan Conway wrote:
Gordon/Rafi: this raises an interesting question for the new APIs. It
seems like async declare/bind/subscribe are important features for cases
like this.
I agree, this is an interesting case. On the face of it my initial
suggestion would be a single receiver for an address using create:
always and a list of binding 20,000 long.
You mean construct a single address string with 20,000 bindings in it?
Wouldn't necessarily need to be done as a string. The
qpid::messaging::Address class can be manipulated directly. However...
That doesn't sound practical. I think we need a way to split apart the
process of constructing a receiver in this case so we can create a
receiver and then incrementally add bindings to it. That would seem like
a useful feature in any case - the set of things a receiver is
interested in may change dynamically over its lifetime so it would be
good to be able to add/remove bindings to a receiver.
...I can see that being a valuable addition for some cases, yes.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
