Oleg,
On 29/10/2012 22:56, Oleg Tsal-Tsalko wrote:
> Hi Nigel,
>
> The definition above states that noLocal can only be set to true if client id is set. However, since the client
> identifier forms part of the name of the subscription, and since you can't have two connections with the same client
> identifier, noLocal can only be set to true if you have only one connection consuming from the subscription (though
> you can still have multiple sessions using that connection).
>
>
> Oh, I see now. But in this case we are really restricting concurrent consumer use case by allowing only concurrent
> sessions in scope of single connection. Isn't it? Probably it is more flexible to allow to specify shared subscription
> name completely up to clients?
The only thing we are restricting is the use of noLocal. This is a concept that was invented for JMS 1.1, when each
subscription could have only one connection.
JMS 2.0 now allows more than one connection to be used with a subscription. That adds greater flexibility in that it
allows multiple connections (or multiple threads on the same connection) to share the work of processing messages from a
durbale or non-durable topic subscription. However we haven't so far been able to devise a useful definition of noLocal
which works with multiple connections (we can invent hypothetical definitions, but no-one has described a realistic use
case to justify them). That's why I think it is OK for noLocal to continue to be restricted to the single connection
case, as in JMS 1.1.
(More views welcome!)
Nigel