Bump this up. I'm essentially in the same boat. The olso.messaging library in Openstack has introduced a feature called 'consumer pools' which is essentially the same pattern: a set of subscribers to a topic can belong to a pool. Each distinct pool of subscribers get a copy of the message sent to the topic, and only one subscriber from the pool claims the message.
This pattern is available in the JMS 2.0 API via the createdSharedConsumer call [1] I'm particularly interested in how such a feature could be implemented in a qpid-dispatch based federation of brokers. I suspect that all subscribers to a given share would have to belong on the same broker - if shares existed on multiple brokers then each 'sub-share' would get a copy of the same message in violation of the pattern. [1] http://www.oracle.com/technetwork/articles/java/jms2messaging-1954190.html ----- Original Message ----- > From: "Dominic Evans" <[email protected]> > To: [email protected] > Sent: Wednesday, May 6, 2015 7:41:59 AM > Subject: AMQP 1.0 and Shared Subscriptions > > When we were implementing the MQ Light broker, we wanted to be able to > support sharing of subscriptions across a group of clients - in particular > for the worker offload scenario. At the time we were unable to find guidance > in the specification or extensions thereof, so we went ahead with encoding > this into the terminus addresses of an attach. Using a `private:` prefix to > denote an exclusive subscription, and `share:sharename` to indicate a shared > one. > > i.e., > > -> @attach(18) [name="share:sharename:topicname", handle=0, role=true, > snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) > [address="share:sharename:topicname", durable=0, timeout=0, dynamic=false], > target=@target(41) [address="share:sharename:topicname", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0] > > vs > > -> @attach(18) [name="private:topicname", handle=0, role=true, > snd-settle-mode=0, rcv-settle-mode=0, source=@source(40) > [address="private:topicname", durable=0, timeout=0, dynamic=false], > target=@target(41) [address="private:topicname", durable=0, timeout=0, > dynamic=false], initial-delivery-count=0] > > The other day I happened to notice that the qpid-cpp broker also supports a > similar functionality since https://issues.apache.org/jira/browse/QPID-4917 > / https://github.com/apache/qpid/commit/d4dafd3 - and it does this by > supporting a capability of 'shared' on the exchange, and expecting a client > @attach to request this capability, whereupon the link-name is used as-is > for the name of the share. I wasn't able to find this behaviour documented > any further than that, and it wasn't clear to me what the behaviour should > be for the various scenarios. > > Ideally we'd like to conform to a common standard. Does anyone know if there > were any plans to register this (or another) shared subscription behaviour > with the working group as an extension? > > > -- > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > -- -K
