Hi Nigel,
The definition above states that noLocal can only be set to true if client
> id is set. However, since the client identifier forms part of the name of
> the subscription, and since you can't have two connections with the same
> client identifier, noLocal can only be set to true if you have only one
> connection consuming from the subscription (though you can still have
> multiple sessions using that connection).
Oh, I see now. But in this case we are really restricting concurrent
consumer use case by allowing only concurrent sessions in scope of single
connection. Isn't it? Probably it is more flexible to allow to specify
shared subscription name completely up to clients?
Thank you,
Oleg
2012/10/29 Nigel Deakin <nigel.deakin_at_oracle.com>
> Oleg,
>
>
> On 26/10/2012 21:00, Oleg Tsal-Tsalko wrote:
>
> Completely agree that we should clearly define noLocal flag usage and
> create CTS tests for it.
>
>
>> When a durable or shared non-durable subscription is created on a topic,
>> the noLocal argument may be used to specify that messages published to the
>> topic by its own connection or any other with the same client identifier
>> will not be added to the durable subscription. If the client identifier is
>> unset then setting noLocal to true will cause an exception to be thrown.
>
>
> This definition seams clear to me.
>
>
> Note that this definition states that noLocal may only be set to true if
> the client identifier is set.
>
> Note also the proposal (see bottom of email) to change the definition of a
> shared non-durable subscriptions that the client identifier, if set, forms
> part of the name of the shared non-durable subscription (as is already the
> case with durable subscriptions).
>
>
>
> Since only one connection may have a given client identifier at a time,
>> this means that the noLocal flag may only be used when there is a single
>> connection consuming from a subscription.
>
>
> However this one is not. Could you explain what do you mean here?
>
>
> This isn't intended to be part of the definition. Instead it's pointing
> out a consequence of it. The definition above states that noLocal can only
> be set to true if client id is set. However, since the client identifier
> forms part of the name of the subscription, and since you can't have two
> connections with the same client identifier, noLocal can only be set to
> true if you have only one connection consuming from the subscription
> (though you can still have multiple sessions using that connection).
>
> Nigel
>
>
>
> Thank you,
> Oleg
>
> 2012/10/26 Rob Davies <rajdavies_at_gmail.com>
>
>> +1 I think this is a reasonable approach
>> On 26 Oct 2012, at 19:09, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
>>
>> > I'd like to go back to the discussion which I started last month about
>> the meaning of the noLocal flag with shared non-durable subscriptions.
>> >
>> > (This email makes a proposal. For those who want to skip the
>> discussion, scroll down to PROPOSAL below)
>> >
>> > BACKGROUND AND DISCUSSION
>> > -------------------------
>> >
>> > (For full background, see the discussion that followed my comment at
>> >
>> http://java.net/jira/browse/JMS_SPEC-40?focusedCommentId=346148&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_346148
>> )
>> >
>> > We have already defined the behaviour of noLocal with non-shared
>> non-durable subscriptions and for durable subscriptions. However we still
>> have to define what this parameter means with shared non-durable
>> subscriptions. Remember that this feature is new in JMS 2.0 so we can
>> define this to be anything we like. We can even decide not to have a
>> nolocal flag at all if we like.
>> >
>> > In my last posting I wrote that for shared non-durable subscriptions we
>> have two alternatives:
>> >
>> > A. Adopt a rule similar to that for durable subscriptions, based on
>> client identifier:
>> >
>> > "If noLocal is set to true, and the client identifier is set, then any
>> messages published to the topic using the
>> > connection that created the durable subscription, or any other
>> connection with the same client identifier, will not be
>> > added to the durable subscription.
>> >
>> > "If the client identifier is unset then setting noLocal to true will
>> cause a IllegalStateException to be thrown."
>> >
>> > B. Adopt a rule based on whether a connection has created a consumer on
>> the shared subscription:
>> >
>> > "Any messages published by a connection which has created a consumer on
>> the shared non-durable subscription will not be
>> > added to the subscription."
>> >
>> > The only comment I received was from Chris Barrow, who argued that
>> since clientId did not form part of the identity of a non-durable
>> subscription then clientID should not be used as the basis of defining the
>> behaviour of nolocal. (See the JIRA issue for his comments in full). I'm
>> grateful for Chris's suggestion. If I understand his proposal correctly, he
>> was suggesting that the noLocal flag should not control whether the message
>> is added to the subscription, but whether it is delivered from the
>> subscription to a particular consumer.
>> >
>> > I've been considering this general issue more and would like to make a
>> proposal. I think it's clear by now that noLocal is an obscure feature for
>> which we can't define a good use case, especially when there are multiple
>> consumers on the same subscription (which wasn't allowed in JMS 1.1).
>> >
>> > I think that since JMS 1.1 does define a noLocal parameter for durable
>> subscriptions, and for old-style non-durable subscriptions (which I now
>> call non-shared non-durable subscriptions) then our main priority is to be
>> consistent.
>> >
>> > My view is that shared non-durable subscriptions are similar to durable
>> subscriptions in the following says:
>> >
>> > * the subscription has a name
>> > * the subscription can be long-lived, continuing beyond the life of the
>> connection which initially created it
>> > * there can be multiple connections receiving messages from the
>> subscription. These connections are all equal: no connection can be has a
>> special status in respect of the subscription
>> >
>> > This contrasts with old-style non-durable subscriptions (which I now
>> call non-shared non-durable subscriptions):
>> >
>> > * the subscription doesn't have a name
>> > * the subscription lasts only as long as the connection which initially
>> created it
>> > * there is only one connection receiving messages from the
>> subscription, which self-evidently has a special status in respect of the
>> subscription
>> >
>> > There is one significant difference between shared non-durable
>> subscriptions and durable subscriptions:
>> >
>> > * for durable subscriptions, the name of the subscription is a
>> combination of the specified subscription name and, if set, the client
>> identifier, whereas for shared non-durable subscriptions, the name of the
>> subscription is defined as the specified subscription name only.
>> >
>> > PROPOSAL
>> > --------
>> >
>> > Because shared non-durable subscriptions are so similar in concept to
>> durable subscriptions I think we should aim to make the definition of
>> noLocal for the two types of subscription as similar as possible. This
>> means:
>> >
>> > 1. Changing the definition of a shared non-durable subscription so that
>> the client identifier, if set, forms part of the name of the shared
>> non-durable subscription (as is already the case with durable
>> subscriptions).
>> >
>> > 2. Defining noLocal in exactly the same way for shared non-durable
>> subscriptions as for durable subscriptions:
>> >
>> > When a durable or shared non-durable subscription is created on a
>> topic, the noLocal argument may be used to specify that messages published
>> to the topic by its own connection or any other with the same client
>> identifier will not be added to the durable subscription. If the client
>> identifier is unset then setting noLocal to true will cause an exception to
>> be thrown.
>> >
>> > Since only one connection may have a given client identifier at a time,
>> this means that the noLocal flag may only be used when there is a single
>> connection consuming from a subscription. I believe this is a benefit as it
>> it gives us a clear, simple definition, it maintains consistency with JMS
>> 1.1, and avoiding the need to contrive complex and entirely hypothetical
>> use cases in which noLocal is used in conjunction with multiple consumers.
>> >
>> > This is the only aspect of the new shared non-durable subscription that
>> is not yet properly defined. Since I don't want the lack of agreement on
>> this aspect to force the abandonment of the entire feature, I would like to
>> propose that we write this definition into the specification, prepare the
>> CTS tests, and implement the RI on that basis.
>> >
>> > However I will add a special note to section A.3. "Unresolved issues in
>> the JMS 2.0 Public Draft" to state that this is an issue which we aren't
>> completely sure about, and that when this specification goes to public
>> review we're particularly welcome comments on it. (This section already
>> mentions an unresolved issue with delivery delay).
>> >
>> > Please let me know if you think this is a reasonable approach, or if
>> you don't.
>> >
>> > Nigel
>> >
>> >
>>
>>
>