On some recent traces to an ActiveMQ 5.12 broker I observed that the broker
signals some info in the open frame:
capability:ANONYMOUS-RELAY,
property:{topic-prefix:topic://, queue-prefix:queue://}
Having written clients that try to go to ActiveMQ brokers and to Qpid brokers,
getting the queue and topic prefixes from the broker is extremely convenient as
long as the broker requires a prefix. If ActiveMQ needs a prefix, Qpidd uses a
node property, and MQ Light uses different prefixes then interoperability
becomes an issue. I'd much rather see all brokers use the property scheme and
not overload the address with prefixes.
----- Original Message -----
> From: "Gordon Sim" <g...@redhat.com>
> To: us...@qpid.apache.org
> Cc: proton@qpid.apache.org
> Sent: Wednesday, May 6, 2015 10:54:26 AM
> Subject: Re: AMQP 1.0 and Shared Subscriptions
>
> Moving to the user list as this is a more general topic.
>
> On 05/06/2015 12:41 PM, Dominic Evans wrote:
> > 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.
>
> The behaviour is briefly documented in
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/AMQP_1.0.
>
> A link on which messages are to be sent out from the broker, i.e. a
> subscription from the clients perspective, can have the 'shared'
> capability requested on it. If two such subscription requests are made
> with the same link name, then messages for that subscription are
> distributed between those links, rather than each receiving their own copy.
>
> This came out of discussions on the user list:
> http://qpid.2158936.n2.nabble.com/c-Status-of-the-AMQP-1-0-work-td7591137.html#a7594079
>
> > 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?
>
> JMS 2.0 will need something similar (though more complicated), so at
> some point the JMS binding doc will presumably suggest something.
>
