On 26/10/2012 19:09, Nigel Deakin wrote:
>
> PROPOSAL
> --------
>
> Because shared non-durable subscriptions are so similar in concept to durable subscriptions I think we should aim to
> make the definition of noLocal for the two types of subscription as similar as possible. This means:
>
> 1. Changing the definition of a shared non-durable subscription so that the client identifier, if set, forms part of the
> name of the shared non-durable subscription (as is already the case with durable subscriptions).
>
> 2. Defining noLocal in exactly the same way for shared non-durable subscriptions as for durable subscriptions:
>
> When a durable or shared non-durable subscription is created on a topic, the noLocal argument may be used to specify
> that messages published to the topic by its own connection or any other 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
> exception to be thrown.
>
> Since only one connection may have a given client identifier at a time, this means that the noLocal flag may only be
> used when there is a single connection consuming from a subscription. I believe this is a benefit as it it gives us a
> clear, simple definition, it maintains consistency with JMS 1.1, and avoiding the need to contrive complex and entirely
> hypothetical use cases in which noLocal is used in conjunction with multiple consumers.
>
> This is the only aspect of the new shared non-durable subscription that is not yet properly defined. Since I don't want
> the lack of agreement on this aspect to force the abandonment of the entire feature, I would like to propose that we
> write this definition into the specification, prepare the CTS tests, and implement the RI on that basis.
>
> However I will add a special note to section A.3. "Unresolved issues in the JMS 2.0 Public Draft" to state that this is
> an issue which we aren't completely sure about, and that when this specification goes to public review we're
> particularly welcome comments on it. (This section already mentions an unresolved issue with delivery delay).
>
> Please let me know if you think this is a reasonable approach, or if you don't.
So far Rob has supported these proposals. Oleg has asked some questions about it, and Chris made an alternative
suggestion via the JIRA issue which I responded to there.
As I wrote above, I don't want the lack of agreement on this aspect to force the abandonment of the entire feature, so I
have now written this definition into the specification so we can move forward, prepare the CTS tests, and implement the RI.
To see the new text in the spec, please download the latest draft from
http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
and read section 6.11.2. "Shared non-durable subscriptions"
As promised, I have added a special note to section A.3. "Unresolved issues in the JMS 2.0 Public Draft" to state that
this is an issue which we aren't completely sure about, and that when this specification goes to public review we're
particularly welcome comments on it.
You can find the updated API documentation for Session.createSharedConsumer at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/Session.html#createSharedConsumer%28javax.jms.Topic,%20java.lang.String,%20java.lang.String,%20boolean%29
and for JMSContext.createSharedConsumer at
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/JMSContext.html#createSharedConsumer%28javax.jms.Topic,%20java.lang.String,%20java.lang.String,%20boolean%29
I've also updated JMS_SPEC-40 and closed it. (That's a signal that implementation work can begin)
Nigel