Agree - option 3.
On 30 Jan 2013, at 07:19, Chris Barrow <chris.barrow_at_kaazing.com> wrote:
> +1, I agree with John.
>
> Chris
>
> On 1/29/2013 2:01 PM, John Archbold wrote:
>> 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
>>>
>>
>