users@jms-spec.java.net

[jms-spec users] [jsr343-experts] Re: (JMS_SPEC-65) Clarify use of NoLocal arg when using createDurableSubscriber

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 06 Jan 2012 14:36:57 +0000

I refer to this issue:

On 22/12/2011 15:40, Nigel Deakin wrote:
> I have logged the following issue:
> http://java.net/jira/browse/JMS_SPEC-65
>
> This issue relates to the following method on {{javax.jms.Session}}:
>
> TopicSubscriber createDurableSubscriber(Topic topic,
> java.lang.String name,
> java.lang.String messageSelector,
> boolean noLocal)
> throws JMSException
>
> What does noLocal mean in this context? The javadoc states that this method "Creates a durable subscriber to the
> specified topic, using a message selector and specifying whether messages published by its own connection should be
> delivered to it". However it is ambiguous whether "it" refers to the durable subscription in the JMS provider or the
> TopicSubscriber object.
>
> Does noLocal mean
> (1) that messages published by this connection should not be added to the durable subscription, or that
> (2) messages published by this connection should not be delivered to this particular {{TopicSubscriber}}? These do not
> mean the same thing, since in the latter case the messages might be saved in the subscription and delivered at some
> later stage.
>
> This should be clarified.
>
> The suggested interpretation is that it means (1): that messages published by its own connection should not be added to
> the durable subscription.
>
> Comments please. If your own JMS implementation interprets this differently please say so.

I received the following comments:

On 21/12/2011 18:56, Rob Davies wrote:
> My interpretation of this is the former - that messages published by its own connection should not be added to the
> durable subscription.

On JIRA, Hiram Chirino added a comment - 22/Dec/11 04:57 PM

> Agree it should be (1). Otherwise you will get an inconsistent behavior once a consumer reconnects, and lets face it
> folks hate inconsistencies.

In the absence of any suggestions to the contrary, I propose we go for (1). I will draft a suitable wording and send
round details when I've done that.

Nigel