On 12/11/2012 15:20, Nicholas Wright wrote:
> Nigel,
>
> Sorry if I'm late to the party on this one.
>
> I think your approach is reasonable, and the throwing of an exception on a second connection to a non-durable sub
> which is attempting to use a different no-local arg is a valid response to chris's query.
Thanks.
>
> Can we please specify if if is a JMSRuntimeException or JMSException however?
>
This is specified in the actual API docs for the method in question. So for Session.createSharedConsumer it's a
JMSException, whilst for JMSContext.createSharedConsumer it's a JMSRuntimeException. (Methods on JMSContext don't throw
checked exceptions).
Nigel
> Regards,
>
> Nick
>
> Nicholas Wright
> Senior Consultant
> /C2B2 Consulting Ltd
> /*The Leading Independent Middleware Experts*/
> /W: www.c2b2.co.uk| T: (+44) 8450 539457| M: (+44) 7703 193351| @c2b2consulting
> ---------------------------------------------------------------------------------------------------------------
> C2B2 Consulting Limited, Unit 34, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ
> Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire
>
> On 05/11/2012 19:29, Nigel Deakin wrote:
>> 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
>