Hi Nigel,
Given that the intended use of noLocal was for a client that wanted to
broadcast messages on a topic and listen for other broadcasts on that
topic without hearing its own messages (e.g. a simple group chat model),
I vote for option 3, to drop the use of noLocal from shared subscribers.
I don't see an useful intersection between the two.
Thanks,
John
On 1/15/2013 3:52 AM, Nigel Deakin wrote:
> I'd like to discuss another issue listed in Appendix A "Issues" in the
> draft spec.
>
> In this email I'd like to review the issue described in A.3.2 Meaning
> of noLocal with shared topic subscriptions:
>
> ---------------------------------------------------------------------
> JMS 2.0 allows multiple consumers to be created on the same durable or
> non-durable subscription. This means that in some cases more than one
> connection may be being used to consume messages from a subscription.
>
> The definition of the noLocal parameter in JMS 1.1 was written on the
> basis that there would only ever be one connection at a time consuming
> messages from a subscription. This definition therefore became
> ambiguous and inadequate for JMS 2.0 and needed to be revised.
>
> The revised definition may be found in section 6.11.2 "Shared
> non-durable subscriptions" and section 6.11.3 "Durable subscriptions"
> and in the API documentation.
>
> The expert group had some difficulty in finding realistic use cases
> for the use of the noLocal parameter in the case where the
> subscription was shared. It would therefore particularly welcome
> suggestions of real-world use cases which would use this parameter,
> and comments on whether the proposed definition would satisfy such use
> cases.
> ---------------------------------------------------------------------
>
> The reason I recorded this as an issue is explained in the previous
> paragraph. However as things stand we do have a definition of how
> noLocal is handled for all types of subscription, so the question we
> need to answer now is whether we're happy with this or whether we want
> to discuss it further.
>
> We spent quite a lot of time on this and we have a definition of
> noLocal which is unambiguous and capable of being implemented. Here's
> a reminder: (taken from the spec):
>
> * For unshared non-durable subscriptions (not new) we made no changes.
>
> * For a shared-non-durable subscription (not new) we "clarified" the
> spec to say that noLocal argument may be used to specify that messages
> published to the topic by the Session, TopicSession or JMSContext's
> own connection, or any other connection with the same client
> identifier, will not be added to the shared non-durable subscription.
> If the client identifier is unset then setting noLocal to true will
> cause an IllegalStateException or IllegalStateRuntimeException
> (depending on the method signature) to be thrown.
>
> * For an unshared durable subscription (new in JMS 2.0) we wrote that
> the noLocal argument may be used to specify that messages published to
> the topic by the Session, TopicSession or JMSContext's own connection,
> or any other connection with the same client identifier, will not be
> added to the durable subscription.
>
> * For a shared durable subscription (new in JMS 2.0) we wrote that the
> noLocal argument may be used to specify that messages published to the
> topic by the Session, TopicSession or JMSContext's own connection, 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 an IllegalStateException or
> IllegalStateRuntimeException (depending on the method signature) to be
> thrown.
>
> However, as I wrote above, it is not clear to me quite how useful
> noLocal is as a feature, especially as its use of client identifier
> rather limits its use in the case of shared subscriptions. One
> possibility which is worth considering, if only briefly, is dropping
> noLocal completely for shared subscriptions. (We would have to keep it
> for JMS 1.1 unshared subscriptions).
>
> So I think we have the following options:
>
> 1. Do nothing. The definitions we have now are the best we can get,
> and should stay. This is the default option.
>
> 2. Amend the current definitions of noLocal. I have no proposals, but
> if anyone else feels we should consider this please make a proposal.
>
> 3. Drop noLocal from shared subscriptions (both durable and
> non-durable). We should choose this feature if we think noLocal has no
> useful purpose with shared subscriptions. Note that making this choice
> doesn't prevent us adding noLocal in the future.
>
> I would appreciate your views on this.
>
> Nigel
>