----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: proton@qpid.apache.org
> Sent: Wednesday, May 6, 2015 10:25:32 AM
> Subject: Re: AMQP 1.0 and Shared Subscriptions
> 
> 
> 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?

Openstack's particular case may be better solved on the broker due to their 
store-and-forward requirements on notification messages.  oslo.messaging 
expects notifications get queued if there are no current consumers.

In oslo.messaging the notification topic actually acts like a queue - only one 
subscriber consumes the message, and messages are balanced across all 
subscribers.  A shared pool essentially adds another queue, with each pool 
getting its own copy of the message.  A topic may have a mix of shared and 
non-shared subscribers. So the non-pooled subscribers in effect share a default 
'anonymous' queue.

I don't -think- it's required to queue messages for a shared pool, since a pool 
doesn't exist until there are actually subscribers to it.  So maybe we 
implement a hybrid solution similar to what you describe: queue a copy of each 
message to the default queue using a queue route, and anycast a copy to each 
known pool consumer.   That could buy some extra scalability. 



> 
> >
> >
> > [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
> >>
> >>
> >
> 

-- 
-K

Reply via email to