Re: AMQP 1.0 and Shared Subscriptions

[Ted Ross]

On 05/06/2015 10:05 AM, Ken Giusti wrote:
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.

A half-baked idea:

What if we implemented a shared-target in Dispatch?  It's like a 
waypoint except it doesn't have any external component and has no 
connections or links associated with it.

You would configure a shared-target to receive from topic address T and 
send to pool address P.  The semantics for T are multicast (i.e. each 
pool receiving from T will get one copy of every message from T) and the 
semantics for P are anycast (i.e. messages to P will be sent to exactly 
one of the consumers of P).

Would that solve your problem?



[1] http://www.oracle.com/technetwork/articles/java/jms2messaging-1954190.html

----- Original Message -----
From: "Dominic Evans" <dominic.ev...@uk.ibm.com>
To: proton@qpid.apache.org
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