Now we've clarified the meaning of noLocal when creating a durable subscription, we now need to consider what noLocal
means when there are more than one consumers on the same subscription, which is a new feature that we have already added.
Just to remind you, we have already agreed that:
* We allow a durable subscription to have multiple consumers (see JMS_SPEC-40)
* We allow the creation of named non-durable subscriptions which may have multiple consumers (see JMS_SPEC-40).
* We allow client identifier to be unset when creating a durable subscription (see JMS_SPEC-39)
What does this mean for noLocal?
(The following discussion is also at
http://java.net/jira/browse/JMS_SPEC-40?focusedCommentId=346148&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_346148)
We need to consider the following cases:
1. Unshared durable subscription with client identifier set
2. Unshared durable subscription with client identifier unset
3. Shared durable subscription with client identifier set
4. Shared durable subscription with client identifier unset
5. Shared non-durable subscription with client identifier set
6. Shared durable non-subscription with client identifier unset
Let's consider these in turn:
1. Unshared durable subscription with client identifier set
This case is already allowed in JMS 1.1 and the meaning of noLocal has been clarified in JMS_SPEC-65 as follows:
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.
2. Unshared durable subscription with client identifier unset
This case is new in JMS 2.0 and the meaning of noLocal has already been defined in JMS_SPEC-65: this will not be allowed
and will throw an exception.
3. Shared durable subscription with client identifier set
This case is new in JMS 2.0. Since two connections cannot have the same client identifier all consumers on the durable
subscription must use the same connection. We can simply apply the rule given in (1):
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.
4. Shared durable subscription with client identifier unset
This case is new in JMS 2.0. We can simply apply the rule given in (2) and not allow this.
5. Shared non-durable subscription with client identifier set
This case is new in JMS 2.0 and we don't have a rule yet which covers it.
We could simply apply the same rule as for durable subscriptions, given in (1) above. However it should be noted that
unlike for durable subscriptions, the client identifier will not be part of the subscription name and so we may have
multiple consumers with different client identifier. In that case why should we assign a special status to the client
identifier that originally created the subscription?
An alternative is to adopt a rule based not on client identifier but on whether the connection has created a consumer on
the subscription. In that case, once a connection has created a consumer on the subscription its messages would no
longer be added to the subscription. This would then give equal status to all consumers. However it would be
inconsistent with durable subscriptions.
6. Shared durable non-subscription with client identifier unset
If we adopted the same rule as for durable subscriptions we would simply not allow this. However if we adopted the
alternative given in (5) above we could also apply it in this case as well.
Summary
-------
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."
Are there any other options? Which do you prefer, if any?
Nigel