Further to this, a bit of discussion has broken out on the JIRA issue.
http://java.net/jira/browse/JMS_SPEC-40
If you'd like to contribute to this discussion please take a look.
You can make comments via this email thread or via JIRA - though I slightly prefer using this email thread as it's a bit
easier to use.
Nigel
On 13/09/2012 18:38, Nigel Deakin wrote:
> 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