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.
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?
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
> >
> >
>
>