You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2015/05/06 16:54:26 UTC
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Robbie Gemmell <ro...@gmail.com>.
Those properties are basically a workaround for how ActiveMQ formatted
its addresses based on implementation needs. They dont play
particularly nicely if you want to mix with different containers that
have different prefixes (MQLight might even need two, as its input and
output addresses being different), making reply-to a pain for example.
Long term, the need for those properties should hopefully go away,
with the Addressing spec being worked on being a better way to cross
vendor interop.
On 6 May 2015 at 17:12, Chuck Rolke <cr...@redhat.com> wrote:
> 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" <gs...@redhat.com>
>> To: users@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.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Chuck Rolke <cr...@redhat.com>.
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" <gs...@redhat.com>
> To: users@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.
>
Re: AMQP 1.0 and Shared Subscriptions
Posted by Chuck Rolke <cr...@redhat.com>.
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" <gs...@redhat.com>
> To: users@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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 May 2015 at 17:02, Gordon Sim <gs...@redhat.com> wrote:
> On 05/06/2015 04:34 PM, Robbie Gemmell wrote:
>>
>> We progressed an idea around an extended use the 'shared' capability.
>> The main issue with using just the capability and link name is that
>> links have to be unique (in a given direction) based on the
>> conainer-id-1 + link-name + container-id-2 triplet, so for a
>> particular 'broker container' that would limit you to having a single
>> subscriber per set of connections using the same container id, which
>> partly defeats the intent. As a result, we also ended up looking at
>> ways to encode the subscription name into the address.
>
>
> Or use a link property. That was my original intention, but due to
> PROTON-335 I couldn't do so.
Yep that was another option, I just didnt mention it as discussion
mostly steered down the other path in the end, and I felt the email
was more than long enough ;)
>I just relaxed the requirement of a unique name
> in the shared case.
>
<Insert compliance debate here > :)
>> That idea also
>> came up independently because it was felt it would be better
>> conceptually to have different address strings for different shared
>> subscriptions on the same topic, given they would essentially be
>> different [psudeo-] nodes.
>
>
> Personally I don't like cramming too much stuff into the address string,
> especially when there are numerous other explicit fields intended to convey
> additional information.
>
> A 'shared-subscription' link property whose value was the name of the
> subscription to use, would be simple and (in my view) clear, and wouldn't
> need to fit in with any other grand plans for address syntax.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Gordon Sim <gs...@redhat.com>.
On 05/06/2015 05:22 PM, Rob Godfrey wrote:
> So I take the opposite view here I think... Or maybe we just have
> different notions of what a shared subscription is.
>
> To me a shared subscription represents an entity that may currently
> have 0, 1 or many consumers which "compete" for messages amongst each
> other.
I can see that view. I also see the subscribing links as part of a
logical grouping, hence sharing some common group identifier (i.e.
subscription name).
> A link represents encapsulates the state of a conversation between two
> endpoints in (separate) AMQP containers. The state of two consumers
> from the same shared subscription is not in any way shared (or at
> least no more so than two consumers on a standard queue).
>
> To me a shared subscription is a logical "node" which the (broker)
> container presents to clients. It has state... and links
> (subscriptions) to it have state. To me the logical way to represent
> the shared subscription is as an address... - one of the proposals
> that was kicked around was topic[foo] where foo is the shared
> subscription name. As well as what I perceive to be the better
> modelling of the notion of a shared subscription, this form also has
> the advantage of being easily transcribable, and the consuming client
> doesn't actually need to know that the address they are provided with
> represents a shared subscription rather than a queue or another type
> of node.
That is certainly a very useful property. You could also handle that by
'broker' side configuration.
My main concern with the address is that its already used in various
ways that may not be compatible, to describe various different things.
On top of an extremely complex type system and source/target model, we
now need (an increasingly complex) string syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Rob Godfrey <ro...@gmail.com>.
On 6 May 2015 at 18:02, Gordon Sim <gs...@redhat.com> wrote:
> On 05/06/2015 04:34 PM, Robbie Gemmell wrote:
>>
>> We progressed an idea around an extended use the 'shared' capability.
>> The main issue with using just the capability and link name is that
>> links have to be unique (in a given direction) based on the
>> conainer-id-1 + link-name + container-id-2 triplet, so for a
>> particular 'broker container' that would limit you to having a single
>> subscriber per set of connections using the same container id, which
>> partly defeats the intent. As a result, we also ended up looking at
>> ways to encode the subscription name into the address.
>
>
> Or use a link property. That was my original intention, but due to
> PROTON-335 I couldn't do so. I just relaxed the requirement of a unique name
> in the shared case.
>
>> That idea also
>> came up independently because it was felt it would be better
>> conceptually to have different address strings for different shared
>> subscriptions on the same topic, given they would essentially be
>> different [psudeo-] nodes.
>
>
> Personally I don't like cramming too much stuff into the address string,
> especially when there are numerous other explicit fields intended to convey
> additional information.
>
> A 'shared-subscription' link property whose value was the name of the
> subscription to use, would be simple and (in my view) clear, and wouldn't
> need to fit in with any other grand plans for address syntax.
>
So I take the opposite view here I think... Or maybe we just have
different notions of what a shared subscription is.
To me a shared subscription represents an entity that may currently
have 0, 1 or many consumers which "compete" for messages amongst each
other.
A link represents encapsulates the state of a conversation between two
endpoints in (separate) AMQP containers. The state of two consumers
from the same shared subscription is not in any way shared (or at
least no more so than two consumers on a standard queue).
To me a shared subscription is a logical "node" which the (broker)
container presents to clients. It has state... and links
(subscriptions) to it have state. To me the logical way to represent
the shared subscription is as an address... - one of the proposals
that was kicked around was topic[foo] where foo is the shared
subscription name. As well as what I perceive to be the better
modelling of the notion of a shared subscription, this form also has
the advantage of being easily transcribable, and the consuming client
doesn't actually need to know that the address they are provided with
represents a shared subscription rather than a queue or another type
of node.
-- Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Gordon Sim <gs...@redhat.com>.
On 05/06/2015 04:34 PM, Robbie Gemmell wrote:
> We progressed an idea around an extended use the 'shared' capability.
> The main issue with using just the capability and link name is that
> links have to be unique (in a given direction) based on the
> conainer-id-1 + link-name + container-id-2 triplet, so for a
> particular 'broker container' that would limit you to having a single
> subscriber per set of connections using the same container id, which
> partly defeats the intent. As a result, we also ended up looking at
> ways to encode the subscription name into the address.
Or use a link property. That was my original intention, but due to
PROTON-335 I couldn't do so. I just relaxed the requirement of a unique
name in the shared case.
> That idea also
> came up independently because it was felt it would be better
> conceptually to have different address strings for different shared
> subscriptions on the same topic, given they would essentially be
> different [psudeo-] nodes.
Personally I don't like cramming too much stuff into the address string,
especially when there are numerous other explicit fields intended to
convey additional information.
A 'shared-subscription' link property whose value was the name of the
subscription to use, would be simple and (in my view) clear, and
wouldn't need to fit in with any other grand plans for address syntax.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: AMQP 1.0 and Shared Subscriptions
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 May 2015 at 15:54, Gordon Sim <gs...@redhat.com> wrote:
> 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.
>
As Gordon says, when we get to JMS 2.0 the AMQP JMS Mapping doc would
need something in this area, since JMS 2.0 has shared durable and non
durable subscriptions. We are initially doing a 1.1 mapping, but did
spend some time thinking on this to see how it might work in with e.g
the old non-shared durable subscriptions.
We progressed an idea around an extended use the 'shared' capability.
The main issue with using just the capability and link name is that
links have to be unique (in a given direction) based on the
conainer-id-1 + link-name + container-id-2 triplet, so for a
particular 'broker container' that would limit you to having a single
subscriber per set of connections using the same container id, which
partly defeats the intent. As a result, we also ended up looking at
ways to encode the subscription name into the address. That idea also
came up independently because it was felt it would be better
conceptually to have different address strings for different shared
subscriptions on the same topic, given they would essentially be
different [psudeo-] nodes.
We eventually parked the idea and decided to revisit it when we
actually get to JMS 2.0, and quite possibly look at using AMQP
Management to do it instead, because things got horrendously
complicated when adapting things further to enable meeting numerous
additional restrictions needed for JMS subscription semantics.
For those wonderring, some the issues for shared subs with JMS 2.0
included: the requirements for unsubscribing (where you dont know the
topic), combined namespaces for shared and non shared durable
subscriptions that must be distinguishable, sharing across different
connections that might dont a clientid and so might have the same
special containerid (one possibility considered for handling
no-clientid), and creating new subscribers for a subscription with
different topic+selector details which must fail in some situations
but succeed in others. The list goes on.
Robbie
Re: AMQP 1.0 and Shared Subscriptions
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 May 2015 at 15:54, Gordon Sim <gs...@redhat.com> wrote:
> 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.
>
As Gordon says, when we get to JMS 2.0 the AMQP JMS Mapping doc would
need something in this area, since JMS 2.0 has shared durable and non
durable subscriptions. We are initially doing a 1.1 mapping, but did
spend some time thinking on this to see how it might work in with e.g
the old non-shared durable subscriptions.
We progressed an idea around an extended use the 'shared' capability.
The main issue with using just the capability and link name is that
links have to be unique (in a given direction) based on the
conainer-id-1 + link-name + container-id-2 triplet, so for a
particular 'broker container' that would limit you to having a single
subscriber per set of connections using the same container id, which
partly defeats the intent. As a result, we also ended up looking at
ways to encode the subscription name into the address. That idea also
came up independently because it was felt it would be better
conceptually to have different address strings for different shared
subscriptions on the same topic, given they would essentially be
different [psudeo-] nodes.
We eventually parked the idea and decided to revisit it when we
actually get to JMS 2.0, and quite possibly look at using AMQP
Management to do it instead, because things got horrendously
complicated when adapting things further to enable meeting numerous
additional restrictions needed for JMS subscription semantics.
For those wonderring, some the issues for shared subs with JMS 2.0
included: the requirements for unsubscribing (where you dont know the
topic), combined namespaces for shared and non shared durable
subscriptions that must be distinguishable, sharing across different
connections that might dont a clientid and so might have the same
special containerid (one possibility considered for handling
no-clientid), and creating new subscribers for a subscription with
different topic+selector details which must fail in some situations
but succeed in others. The list goes on.
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org