You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Lorenz Quack <qu...@gmail.com> on 2017/01/11 08:51:06 UTC
JMS 2.0 shared subs and clientId
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 \u2018in use\u2019 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 \u2018sharing\u2019 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
Re: JMS 2.0 shared subs and clientId
Posted by Lorenz Quack <qu...@gmail.com>.
Hi Robbie,
As per my other email I think we agree and just have
difficulties communicating our thoughts.
I do not have further comments for the time being :)
Kind regards,
Lorenz
On 11/01/17 10:43, Robbie Gemmell wrote:
> Yes. Each connection that has a ClientID is effectively setting a
> namepace. As covered by the JMS spec snippet you quoted, tracking
> state per-name is essentially all the JMS ClientID is used for. It
> used to be mandatory for durable subs, but now isn't, and not
> specifying a ClientID is then in itself another state grouping.
> Accounting for the various further naming restrictions placed on the
> different subscription types (durable/volatile, shared/non-shared,
> ClientID set/not-set etc), you end up with the 5 distinct effective
> [sub-]spaces outlined in the JIRA, with the volatile non-shared ones
> being their own special almost irrelvant randomly named one as you
> note.
>
> Robbie
>
> On 11 January 2017 at 10:21, Lorenz Quack <qu...@gmail.com> wrote:
>> Hello again,
>>
>> Alex just pointed out to me that I missed an important part of
>> the JMS 2.0 spec. In chapter 8.3 it says:
>> A shared non-durable subscription is identified by a name
>> specified by the client and by the client identifier if set.
>> I take that to mean that each client Id should have their own
>> separate namespace. Maybe that is what was meant in QPIDJMS-220?
>>
>> In this case I retract my previous proposal and just propose a
>> clarification to QPIDJMS-220:
>> * Each clientId creates their own namespace
>> * If no clientId is set this is treated like a separate
>> anonymous namespace
>> * Within each of those namespaces there exists the following
>> sub-namespaces:
>> * Durable (shared + non-shared) with durable, non-share
>> requiring a clientId
>> * Volatile shared
>> * Volatile non-shared are somewhat special in that they have a
>> randomly assigned name so they should never conflict with
>> anything
>>
>>
>> Kind regards,
>> Lorenz
>>
>>
>>
>> On 11/01/17 08:51, Lorenz Quack 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 \u2018in use\u2019 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 \u2018sharing\u2019 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
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
Yes. Each connection that has a ClientID is effectively setting a
namepace. As covered by the JMS spec snippet you quoted, tracking
state per-name is essentially all the JMS ClientID is used for. It
used to be mandatory for durable subs, but now isn't, and not
specifying a ClientID is then in itself another state grouping.
Accounting for the various further naming restrictions placed on the
different subscription types (durable/volatile, shared/non-shared,
ClientID set/not-set etc), you end up with the 5 distinct effective
[sub-]spaces outlined in the JIRA, with the volatile non-shared ones
being their own special almost irrelvant randomly named one as you
note.
Robbie
On 11 January 2017 at 10:21, Lorenz Quack <qu...@gmail.com> wrote:
> Hello again,
>
> Alex just pointed out to me that I missed an important part of
> the JMS 2.0 spec. In chapter 8.3 it says:
> A shared non-durable subscription is identified by a name
> specified by the client and by the client identifier if set.
> I take that to mean that each client Id should have their own
> separate namespace. Maybe that is what was meant in QPIDJMS-220?
>
> In this case I retract my previous proposal and just propose a
> clarification to QPIDJMS-220:
> * Each clientId creates their own namespace
> * If no clientId is set this is treated like a separate
> anonymous namespace
> * Within each of those namespaces there exists the following
> sub-namespaces:
> * Durable (shared + non-shared) with durable, non-share
> requiring a clientId
> * Volatile shared
> * Volatile non-shared are somewhat special in that they have a
> randomly assigned name so they should never conflict with
> anything
>
>
> Kind regards,
> Lorenz
>
>
>
> On 11/01/17 08:51, Lorenz Quack 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
Re: JMS 2.0 shared subs and clientId
Posted by Lorenz Quack <qu...@gmail.com>.
Hello again,
Alex just pointed out to me that I missed an important part of
the JMS 2.0 spec. In chapter 8.3 it says:
A shared non-durable subscription is identified by a name
specified by the client and by the client identifier if set.
I take that to mean that each client Id should have their own
separate namespace. Maybe that is what was meant in QPIDJMS-220?
In this case I retract my previous proposal and just propose a
clarification to QPIDJMS-220:
* Each clientId creates their own namespace
* If no clientId is set this is treated like a separate
anonymous namespace
* Within each of those namespaces there exists the following
sub-namespaces:
* Durable (shared + non-shared) with durable, non-share
requiring a clientId
* Volatile shared
* Volatile non-shared are somewhat special in that they have a
randomly assigned name so they should never conflict with
anything
Kind regards,
Lorenz
On 11/01/17 08:51, Lorenz Quack 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 \u2018in use\u2019 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 \u2018sharing\u2019 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
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2017 at 15:21, Lorenz Quack <qu...@gmail.com> wrote:
> Hello,
>
> Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid
> Broker for Java support for JMS 2.0 shared subscriptions.
> This is a follow-up from that discussion.
>
> We discussed that it would be helpful to have a document describing the
> broker behaviour purely in AMQP 1.0 terms.
> Alex and I went ahead and created such a document [1].
> We noticed a problem with unsubscribe as it is described in QPIDJMS-220.
> There it is specified that unsubscription can be done with an Attach with a
> null Source and that the broker should refuse the Link if it cannot find the
> Queue the Link is referring to. This seems to violate the AMQP spec which
> allows null Source Attachs.
> Please review/comment.
>
> Kind regards,
> Lorenz and Alex
>
>
> [1]
> https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support
>
I had a look at the page and it seems good overall, some small comments:
The assumption that the address will be 'exchange/binding' should
perhaps also cover what happens when there is no /binding part given.
I'd probably expect that to receive all messages sent on the exchange,
at least assuming its of the topic type (and obviously for fanout
too).
With how things are specified/implemented, the client will look for
the "SHARED-SUBS" connection capability first, and then if that is not
offered by the server, it sets it as a desired capability on its
shared subscriber links and inspects the response attach for it being
offered. It probably doesnt hurt to always offer it on the link, but
its not required (and in the YES / NO / NO / NO case from the table it
would also not be set as desired since it isn't a shared
subscription).
Perhaps worth adding that the "YES / NO / YES / NO" case doesn't make
much sense, as a non-durable 'global' sub that isn't shared can't
actually be used 'globally', so it is as mentioned effectively the
same as the regular volatile subscriber case. Non-shared, global isn't
a combination I thought of actually being used.
You could say this "YES / NO / YES / YES" makes more sense than above,
e.g. allowing 1 'global' consumer to use it at a time, depending on
the precise behaviour implied by the 'link' exclusivity policy, though
again its not a combination I originally thought of as being used. The
'If queue already exists' bit of the description seems like it would
need tweaked, since at last some combination of link details has to be
able to [re-]attach to this durable subscription, perhaps the text
means 'in use by consumer' instead of 'exists'?
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2017 at 16:55, Lorenz Quack <qu...@gmail.com> wrote:
>
>
> On 12/01/17 16:07, Robbie Gemmell wrote:
>>
>> On 12 January 2017 at 15:21, Lorenz Quack <qu...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid
>>> Broker for Java support for JMS 2.0 shared subscriptions.
>>> This is a follow-up from that discussion.
>>>
>>> We discussed that it would be helpful to have a document describing the
>>> broker behaviour purely in AMQP 1.0 terms.
>>> Alex and I went ahead and created such a document [1].
>>> We noticed a problem with unsubscribe as it is described in QPIDJMS-220.
>>> There it is specified that unsubscription can be done with an Attach with
>>> a
>>> null Source and that the broker should refuse the Link if it cannot find
>>> the
>>> Queue the Link is referring to. This seems to violate the AMQP spec which
>>> allows null Source Attachs.
>>> Please review/comment.
>>>
>> What its meaning is that the 'null source lookup' reciever attach
>> should be responded to with ab attach with a null source if there is
>> no subscription, i.e there is no existing source that the broker can
>> provide the details for to complete the details of the link attach for
>> that named link. See an example in Figure 2.33 and 2.36 of the spec
>> for refusing and recovering links, albeit for the reverse case of a
>> client sending link,
>>
>> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568.
>>
>
> I was referring to the part "Existing non-shared subscriber
> behaviour (used for JMS 1.1)" of QPIDJMS-220 where it says:
>
> "[...] this is utilised by Session#unsubscribe by attaching a
> receiving link using the subscription name, with a null Source,
> requiring the server to perform a lookup for an existing
> subscription using this link name. If none is found then the
> link is refused and the client throws an exception, [...]"
>
> Are you saying that it is okay if the broker does not refuse the
> link? That seems to contradict the above quote. From an AMQP
> perspective I don't see a reason a Attach of a Receiving Link as
> in this case with a null Source should fail so I would always
> accept such Attachs.
>
>
I discussed this with lorenz, and after some digging around the AMQP
spec (mainly around section 2.6.3) and discussion of the [JMS]
unsubscribe process in general, I think we are good now on how these
bits work.
>>> Kind regards,
>>> Lorenz and Alex
>>>
>>>
>>> [1]
>>>
>>> https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: JMS 2.0 shared subs and clientId
Posted by Lorenz Quack <qu...@gmail.com>.
On 12/01/17 16:07, Robbie Gemmell wrote:
> On 12 January 2017 at 15:21, Lorenz Quack <qu...@gmail.com> wrote:
>> Hello,
>>
>> Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid
>> Broker for Java support for JMS 2.0 shared subscriptions.
>> This is a follow-up from that discussion.
>>
>> We discussed that it would be helpful to have a document describing the
>> broker behaviour purely in AMQP 1.0 terms.
>> Alex and I went ahead and created such a document [1].
>> We noticed a problem with unsubscribe as it is described in QPIDJMS-220.
>> There it is specified that unsubscription can be done with an Attach with a
>> null Source and that the broker should refuse the Link if it cannot find the
>> Queue the Link is referring to. This seems to violate the AMQP spec which
>> allows null Source Attachs.
>> Please review/comment.
>>
> What its meaning is that the 'null source lookup' reciever attach
> should be responded to with ab attach with a null source if there is
> no subscription, i.e there is no existing source that the broker can
> provide the details for to complete the details of the link attach for
> that named link. See an example in Figure 2.33 and 2.36 of the spec
> for refusing and recovering links, albeit for the reverse case of a
> client sending link,
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568.
>
I was referring to the part "Existing non-shared subscriber
behaviour (used for JMS 1.1)" of QPIDJMS-220 where it says:
"[...] this is utilised by Session#unsubscribe by attaching a
receiving link using the subscription name, with a null Source,
requiring the server to perform a lookup for an existing
subscription using this link name. If none is found then the
link is refused and the client throws an exception, [...]"
Are you saying that it is okay if the broker does not refuse the
link? That seems to contradict the above quote. From an AMQP
perspective I don't see a reason a Attach of a Receiving Link as
in this case with a null Source should fail so I would always
accept such Attachs.
>> Kind regards,
>> Lorenz and Alex
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
On 12 January 2017 at 15:21, Lorenz Quack <qu...@gmail.com> wrote:
> Hello,
>
> Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the Qpid
> Broker for Java support for JMS 2.0 shared subscriptions.
> This is a follow-up from that discussion.
>
> We discussed that it would be helpful to have a document describing the
> broker behaviour purely in AMQP 1.0 terms.
> Alex and I went ahead and created such a document [1].
> We noticed a problem with unsubscribe as it is described in QPIDJMS-220.
> There it is specified that unsubscription can be done with an Attach with a
> null Source and that the broker should refuse the Link if it cannot find the
> Queue the Link is referring to. This seems to violate the AMQP spec which
> allows null Source Attachs.
> Please review/comment.
>
What its meaning is that the 'null source lookup' reciever attach
should be responded to with ab attach with a null source if there is
no subscription, i.e there is no existing source that the broker can
provide the details for to complete the details of the link attach for
that named link. See an example in Figure 2.33 and 2.36 of the spec
for refusing and recovering links, albeit for the reverse case of a
client sending link,
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568.
> Kind regards,
> Lorenz and Alex
>
>
> [1]
> https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support
>
>
>
> ---------------------------------------------------------------------
> 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: JMS 2.0 shared subs and clientId
Posted by Lorenz Quack <qu...@gmail.com>.
Hello,
Robbie, Rob, Alex, and I had a discussion on IRC yesterday about the
Qpid Broker for Java support for JMS 2.0 shared subscriptions.
This is a follow-up from that discussion.
We discussed that it would be helpful to have a document describing the
broker behaviour purely in AMQP 1.0 terms.
Alex and I went ahead and created such a document [1].
We noticed a problem with unsubscribe as it is described in QPIDJMS-220.
There it is specified that unsubscription can be done with an Attach
with a null Source and that the broker should refuse the Link if it
cannot find the Queue the Link is referring to. This seems to violate
the AMQP spec which allows null Source Attachs.
Please review/comment.
Kind regards,
Lorenz and Alex
[1]
https://cwiki.apache.org/confluence/display/qpid/JMS+2.0+shared+subscription+support
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
On 11 January 2017 at 11:40, Lorenz Quack <qu...@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 <qu...@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
Re: JMS 2.0 shared subs and clientId
Posted by Lorenz Quack <qu...@gmail.com>.
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.
> 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.
> 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.
Kind regards,
Lorenz
>
> On 11 January 2017 at 08:51, Lorenz Quack <qu...@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 \u2018in use\u2019 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 \u2018sharing\u2019 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
Re: JMS 2.0 shared subs and clientId
Posted by Robbie Gemmell <ro...@gmail.com>.
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 ;)
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...
Using a fixed container-id for all non-ClientID-using JMS connections
was actually the original idea when we were first thought on this in
years past (there have been *many* variations before arriving at this
one). In the end we elected not to pursue that as it has some issues,
especially when interacting with the shared subscriptions stuff. For
example:
- If multiple connections are using a fixed container-id, each needs
to name links they produce uniquely or risk stepping on another
connections toes by stealing its links (or just generally violating
the spec) given they share a container-id. This makes it likely that
over time we would be unable to reuse the same names for a given
durable subscription (without the client somehow persisting it),
creating new link names link over time and effectively forgetting
about the old ones.
- The link naming issue makes JMS durable subscription unsubscribe
(which need be based on only the link name) similarly a problem.
- It forces non-JMS clients to adjust their container naming to use
the same mechanism and share such subscriptions with such connections.
I actually see no reason that non-JMS clients shouldn't be able to
share subscriptions across container-id's, if they choose to (the
subscriptions must be marked for such to be possible, so it isnt true
that any client can access state they should not be able to) i.e have
their own container-scoped [shared] subscriptions but also access
subscriptions shared across any container. I consider the fact JMS 2.0
forces you use two different connections in that scenario to be a poor
aspect of the spec additions, it was actually one of the very first
things that hit me when I read the JMS 2 spec originally.
- It just seems nicer for connections to have their own container-id's
than all using the same one, especially given some things use the
container for naming as well.
- I think there were other reasons, but there have been so many minute
details with the various ideas gone through before settling on this,
that I can honestly no longer remember many of them.
Robbie
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.
On 11 January 2017 at 08:51, Lorenz Quack <qu...@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