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