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