qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: questions regarding QPIDJMS-220
Date Wed, 14 Dec 2016 18:59:10 GMT
On 14 December 2016 at 15:47, Lorenz Quack <quack.lorenz@gmail.com> wrote:
> Hello,
> I was looking at QPIDJMS-220 [1] to see whether we could add
> support for shared subscriptions to the Qpid Broker for Java and
> was wondering about the proposed name of the connection/link
> capability: SHARED-SUBS
> That seems very generic.  Considering this is a vendor specific
> extension would a more scoped name be more appropriate?  I saw
> that there seems to be precedent [2] for this naming convention:
> But then again, if my reading of the code is correct, the QPIDJMS
> client does not seem to follow that naming convention.  Is there
> a reason for this?

Keeping it generic was somewhat deliberate, I don't really consider it
to be particularly vendor specific. One reason it exists is to support
a standard mapping to a vendor-neutral API, for example. We could
certainly have called it something like that but I didn't see a
particular need in this case.

> Another question that came up when reading [1] was the use
> of "global" to describe the namespace for subscriptions without
> clientId.  In my mind that is a bit unfortunate because to me it
> suggests something global is also available locally and when
> considering uniqueness you would consider local AND global.
> What it is used for in this context seems to be an anonymous
> namespace in contrast to the ones named by clientId.  In other
> words it is a sibling to the other namespaces rather than at a
> different level of the abstract space hierarchy.

To be clear, in the JMS scenario it would only used by clients that
dont have a ClientID set, but non-JMS clients would be free to use
this whenever they like.

Link names are being used to convey the subscription name information,
and those link names are container-scoped in terms of their
uniqueness, something thats baked into the core spec and doesnt change
with this scenario. The 'global' flag is then being used on top of
this in concert with the 'shared' flag to indicate the subscription
name derived should be applied in a non-container-scoped fashion, such
that all containers doing similarly also access the same subscription,
i.e. it is a globablly accessible subscription rather than jsut
container scoped. This does not remove the need for link names to be
unique per-container however, and not violating that is part of the
reasoning for the naming scheme mentioned, to facilitate a way of
using multiple unique link names both for the same subscription or for
different types of subscription with the same subscription name (but
not link names) at the same time. Servers enforcing the appropriate
access to a global/not-global subscriptions based on a given link name
is something listed in the section at the end.

I actually shamelessly stole that particular name and much of the idea
from a previous semi-unrelated discussion with Gordon. I thought the
name was fairly appropriate to what it is doing personally.


(This might have been easier to spot as a reply to the thread about
this stuff on the users list)

> Kind regards,
> Lorenz
> [1] https://issues.apache.org/jira/browse/QPIDJMS-220
> [2] https://www.amqp.org/specification/1.0/filters
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message