qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: JMS 2.0 shared subs and clientId
Date Wed, 11 Jan 2017 11:59:56 GMT
On 11 January 2017 at 11:40, Lorenz Quack <quack.lorenz@gmail.com> wrote:
> Hi Robbie,
>
> answers are in-line.
>
> On 11/01/17 10:24, Robbie Gemmell wrote:
>>
>> Hi Lorenz,
>>
>> Your timing couldn't be better/worse hehe. As you hadnt replied
>> following the related mail a month or so ago, I didn't think there was
>> more to discuss on this. I had actually planned to start doing the
>> release right about now...I almost got to it yesterday, alas ;)
>
>
> Sorry, I am not sure what email you are talking about.
> I never received an email regarding this issue.
> Specifically, my email with subject "questions regarding
> QPIDJMS-220" went unanswered from my point of view.
> I also just checked my spam folder.  Nothing.  Weird.
>

Ah. I did reply, twice, they must have gone missing en route. The
thread is archived at:
https://lists.apache.org/thread.html/30bcbfd86af6b4a10e547f70e0d6e4b1c82052b43ff71ff95e5eec46@%3Cdev.qpid.apache.org%3E

>> I am unclear from the text exactly how you are proposing to access
>> this 'anonymous namespace'. The JMS ClientID is being carried using
>> the AMQP connection container-id, which is a mandatory field to
>> specify, so a container-id must be given. Did you mean for example to
>> have all JMS clients without a ClientID use some fixed value as their
>> container ID (e.g. empty string, which as rather an aside, could clash
>> with ideas such as those in
>> https://issues.apache.org/jira/browse/QPID-7605)? Assuming that is the
>> case...
>> [*snip*]
>
>
> Yes, I wasn't aware of all the details and problems and naively
> assumed that the container-id was empty/null if there was no
> clientId. Obviously, I had not verified this.
> My understanding now is that it is the "global" Source capability
> that indicates that there is no clientId and the container-id
> should be ignored; at least as far as subscriptions are concerned.

Effectively, yes. For the JMS clients, all shared subscriptions will
be marked 'global' when there is no ClientID set.

>>
>> Actually, re-reading the last section, I appear to have misinterpreted
>> it on my first read through and so did not address it before
>> considering any the above. I'll address is separetely now:
>>
>> "For example, if a client with ID "foo" has a shared subscription
>> called "mysub" a client with ID "bar" would be prevented from also
>> creating a subscription of the name"
>>
>> That would violate the JMS spec. Clients with different ClientIDs are
>> allowed to use the same subscription names at the same time.
>>
>> "while a client without ID would be allowed to do this under the
>> QPIDJMS-220 scheme."
>>
>> As they should. By not having a ClientID, they are not using the "foo"
>> or "bar" ID and so should be allowed to create a subscription named
>> "mysub" atthe same time, which only other connections without a
>> ClientID can use.
>
>
> I think this was addressed by my second email and leads me to think
> that we are now in agreement.
>

Yep, I had just cross-posted as your second mail arrived.

>
> Kind regards,
> Lorenz
>
>
>
>>
>> On 11 January 2017 at 08:51, Lorenz Quack <quack.lorenz@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Sorry for the slightly lengthy email.
>>>
>>> tl;dr: I propose to change to the way JMS 2.0 subscriptions are
>>>         treated in the face of the (non-)existence of a clientId as
>>>         compared to what is outlined in QPIDJMS-220.
>>>
>>>
>>> Introduction:
>>> =============
>>> I am working on adding support for JMS 2.0 shared subscriptions
>>> [1] to the Qpid Broker for Java using the mechanisms outlined in
>>> QPIDJMS-220 [2].
>>>
>>> In QPIDJMS-220 it is outlined that there are essentially 5
>>> disjunct subscription namespaces:
>>>   * durable, shared and non-shared, with clientId
>>>   * durable, shared, without clientId
>>>   * volatile, shared, with clientId
>>>   * volatile, shared, without clientId
>>>   * volatile, non-shared, with and without clientId
>>> while durable, non-shared, without clientId being disallowed by
>>> the spec.
>>>
>>> While I think this is spec compliant I find it unintuitive and
>>> would like to discuss a different partitioning that, according to
>>> my interpretation of the spec, is also compliant.
>>>
>>>
>>> Proposal:
>>> =========
>>> The difference essentially comes down to the treatment of the
>>> clientId.  To me the clientId is like a namespace and not
>>> specifying it gives you access to an anonymous namespace (what
>>> QPIDJMS-220 calls "global").  In this it should be treated no
>>> different from other named namespaces resulting in the following
>>> partitioning:
>>>   * durable, shared and non-shared, regardless of clientId
>>>   * volatile, shared, regardless of clientId
>>>   * volatile, non-shared, regardless of clientId
>>> with durable, non-shared, without clientId being disallowed by
>>> the spec.
>>>
>>>
>>> Relevant parts of the Specification:
>>> ====================================
>>>  From JMS 2.0 Section 8.3.2 Shared non-durable subscriptions:
>>>      There is no restriction to prevent a shared non-durable
>>>      subscription and a durable subscription having the same name. Such
>>>      subscriptions would be completely separate.
>>>
>>>  From JMS 2.0 Section 6.1.3 Client identifier:
>>>      The purpose of client identifier is to associate a connection and
>>>      its objects with a state maintained on behalf of the client by a
>>>      provider. By definition, the client state identified by a client
>>>      identifier can be ‘in use’ by only one client at a time. A JMS
>>>      provider must prevent concurrently executing clients from using
>>>      it.
>>>      This prevention may take the form of a JMSException being thrown
>>>      when such use is attempted; it may result in the offending client
>>>      being blocked; or some other solution. A JMS provider must ensure
>>>      that such attempted ‘sharing’ of an individual client state does
>>>      not result in messages being lost or doubly processed.
>>>
>>>
>>> Discussion:
>>> ===========
>>> As mentioned above I think both schemes are spec compliant.  The
>>> difference is how they prevent concurrently executing clients from
>>> using each others state.  Section 6.1.3 allows the prevention to take
>>> the form of a JMSException (my proposal) or "some other solution"
>>> (QPIDJMS-220, a.k.a. separate namespaces).
>>>
>>> The reason for this I proposal is that I think it is a more natural
>>> and intuitive partitioning with easier to understand rules.
>>> For example, if a client with ID "foo" has a shared subscription
>>> called "mysub" a client with ID "bar" would be prevented from also
>>> creating a subscription of the name while a client without ID would be
>>> allowed to do this under the QPIDJMS-220 scheme.  Under my proposed
>>> scheme both, the "bar" client and the anonymous client, would be
>>> prevented from creating the subscription.
>>> Admittedly, it also makes my life as an implementor easier.
>>>
>>> Is there a use-case or rational for the schema proposed in QPIDJMS-220
>>> that I am not aware of?
>>>
>>>
>>>
>>> Kind regards,
>>> Lorenz
>>>
>>> [1] Chapters 8.3 and 6.1.2 of the JMS 2.0 specification
>>> [2] https://issues.apache.org/jira/browse/QPIDJMS-220
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message