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 19:02:59 GMT
On 14 December 2016 at 18:59, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
> 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:
>> APACHE.ORG:SHARED-SUBS
>> 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

...to be a little clearer, note I'm talking from view of the 'client'
container at this point, given the uniqueness is in a particular
direction between two named containers.

>, 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.
>
> Robbie
>
> (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


Mime
View raw message