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.
Can we please specify if if is a JMSRuntimeException or JMSException
however?
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