Thanks for your comments, Chris.
I'd like to invite more views on this issue. See my email (quoted below) for a reminder of what this is all about.
Nigel
On 15/01/2013 16:14, Chris Barrow wrote:
> Hi Nigel,
>
> I would vote for option "3. Drop noLocal from shared subscriptions (both durable and non-durable)", because I can't
> think of a use case, and I think it would simplify the API. As it stands, the behavior (although carefully described) is
> hard to understand, and moreover, I think the less we rely on client IDs the better!
>
> Chris
>
> 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
>