+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
>>
>