I have logged this issue
http://java.net/jira/browse/JMS_SPEC-93
(This came up when I was working on an updated text for
http://java.net/jira/browse/JMS_SPEC-40, which I plan to present
shortly)
I'd welcome views on this, especially from JMS implementers. I'll also ask whether the CTS tests require on or the other
behaviours.
Does changing the noLocal flag when connecting to a durable subscription cause the durable subscription to be deleted?
----------------------------------------------------------------------------------------------------------------------
The JMS 1.1 specification, section 6.11.1 "Durable TopicSubscriber" states:
"A client can change an existing durable subscription by creating a durable TopicSubscriber with the same name and a new
topic and/or message selector, or NoLocal attribute. Changing a durable subscription is equivalent to deleting and
recreating it"
However the javadoc
http://docs.oracle.com/javaee/6/api/javax/jms/Session.html#createDurableSubscriber%28javax.jms.Topic,%20java.lang.String,%20java.lang.String,%20boolean%29
for the Session method
createDurableSubscriber(Topic topic, java.lang.String name, java.lang.String messageSelector, boolean noLocal)
states that
"A client can change an existing durable subscription by creating a durable TopicSubscriber with the same name and a new
topic and/or message selector. Changing a durable subscriber is equivalent to unsubscribing (deleting) the old one and
creating a new one. "
The latter text uses an almost identical sentence but does not mention the effect of creating a durable subscriber with
a different value of the noLocal flag.
This is contradictory and needs to be clarified. What is the effect if creating a durable subscriber with a different
value of the noLocal flag than was used when the durable subscription was created?
I propose that we should interpret the javadoc as being correct and change the spec to match. The NoLocal flag
determines whether messages sent using the connection that created the durable subscription should be added to it. Its
significance ceases when the connection is closed. If the second call to createDurableSubscription uses a different
connection then the value of noLocal that it specifies is completely independent of the previous value and does not
render the durable subscription invalid. It is therefore not necessary to delete the durable subscription and create a
new one.