You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2012/02/13 18:36:39 UTC
handling no-local for existing queues
IIRC the no-local argument is passed on during queue-declare.
But if you create a subscription with no-local=true on an existing
queue how should we handle this situation ?
Perhaps there is also a way to pass no-local in the arguments map when
creating a subscription ?
Regards,
Rajith
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Gordon Sim <gs...@redhat.com>.
On 02/13/2012 09:59 PM, Rob Godfrey wrote:
> A client can disconnect, and a new connection subscribe, both with
> no-local set, but obviously "no-local" now has a different meaning
> (since the connection in question is different).
One could argue that changing the value of no-local changes that
subscription and as for changes to the selector 'changing a durable
subscriber is equivalent to unsubscribing (deleting) the old one and
creating a new one'[1]
When no-local is set it should always refer to the currently active
connection of course.
[1]
http://docs.oracle.com/javaee/1.4/api/javax/jms/Session.html#createDurableSubscriber%28javax.jms.Topic,%20java.lang.String,%20java.lang.String,%20boolean%29
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Rob Godfrey <ro...@gmail.com>.
One could argue that the "no-local" should be treated the same way as
selectors on a durable subscription - that is that the "no-local"ness
is somehow encoded into the binding (if queue has exclusive consumer
and consumer connection == producer consumer then don't enqueue)
Certainly seems wrong to be retaining those messages
-- Rob
On 13 February 2012 23:03, Robbie Gemmell <ro...@gmail.com> wrote:
> On 13 February 2012 21:59, Rob Godfrey <ro...@gmail.com> wrote:
>> <*snip*>
>>
>>>>> The client currently only sends the no-local argument during queue
>>>>> creation as you mentioned, but there is support in the protocol for
>>>>> adding arguments to subscriptions so it could potentially be added
>>>>> there too (The protocol actually has a no-local field on the file and
>>>>> stream consume methods, so why it doesn't on the standard subscribe
>>>>> method I'm not sure).
>>>>
>>>> I vaguely remembered something like this hence the question.
>>>> Again speaking with Gordon I found the C++ broker does not support
>>>> no-local being sent as an argument during subscription.
>>>> However given the requirements around no-local for JMS I believe we
>>>> can just get away with Topics and not worry about Queues.
>>
>> The "interesting" problem is durable subscriptions I would have
>> thought - which are essentially queues. A client can disconnect, and
>> a new connection subscribe, both with no-local set, but obviously
>> "no-local" now has a different meaning (since the connection in
>> question is different).
>>
>> -- Rob
>>
>
> DurSubs and no-local are interesting. E.g.
> https://issues.apache.org/jira/browse/QPID-3605 :)
>
> Robbie
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 February 2012 21:59, Rob Godfrey <ro...@gmail.com> wrote:
> <*snip*>
>
>>>> The client currently only sends the no-local argument during queue
>>>> creation as you mentioned, but there is support in the protocol for
>>>> adding arguments to subscriptions so it could potentially be added
>>>> there too (The protocol actually has a no-local field on the file and
>>>> stream consume methods, so why it doesn't on the standard subscribe
>>>> method I'm not sure).
>>>
>>> I vaguely remembered something like this hence the question.
>>> Again speaking with Gordon I found the C++ broker does not support
>>> no-local being sent as an argument during subscription.
>>> However given the requirements around no-local for JMS I believe we
>>> can just get away with Topics and not worry about Queues.
>
> The "interesting" problem is durable subscriptions I would have
> thought - which are essentially queues. A client can disconnect, and
> a new connection subscribe, both with no-local set, but obviously
> "no-local" now has a different meaning (since the connection in
> question is different).
>
> -- Rob
>
DurSubs and no-local are interesting. E.g.
https://issues.apache.org/jira/browse/QPID-3605 :)
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Rob Godfrey <ro...@gmail.com>.
<*snip*>
>>> The client currently only sends the no-local argument during queue
>>> creation as you mentioned, but there is support in the protocol for
>>> adding arguments to subscriptions so it could potentially be added
>>> there too (The protocol actually has a no-local field on the file and
>>> stream consume methods, so why it doesn't on the standard subscribe
>>> method I'm not sure).
>>
>> I vaguely remembered something like this hence the question.
>> Again speaking with Gordon I found the C++ broker does not support
>> no-local being sent as an argument during subscription.
>> However given the requirements around no-local for JMS I believe we
>> can just get away with Topics and not worry about Queues.
The "interesting" problem is durable subscriptions I would have
thought - which are essentially queues. A client can disconnect, and
a new connection subscribe, both with no-local set, but obviously
"no-local" now has a different meaning (since the connection in
question is different).
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Robbie Gemmell <ro...@gmail.com>.
On 13 February 2012 19:42, Rajith Attapattu <ra...@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell
> <ro...@gmail.com> wrote:
>> I cross-posted this on the JIRA so I'll report it here incase anyone
>> wants a discussion :)
>>
>>
>> I think the JIRA title is perhaps a little misleading, given the
>> number of tests running that show it does work to an extent.
>
> Actually it should have been (corrected now) does not work when using
> address strings.
> The fix for QPID-3539 was only added to the BURL part.
>
QPID-3539 was really just a Java broker change from what I remember,
where the 0-10 path was incorrectly handling no-local at the session
rather than connection level. I dont think the clients behaviour was
modified at all, so it must have worked already for the BURL paths.
>> Perhaps 'doesn't work when used on queues not originally declared no-local'
>> would be clearer. The BURL usage may always send the queue declare,
>> but redeclaring a queue that exists wont make it no-local.
>
> My bad, the intention of the JIRA was to address the issue of no-local
> not working when using address strings.
> But it seems I have unintentionally highlighted the issue of no-local
> not working for existing queues.
>
> Speaking with Gordon, it seems, at-least from a JMS POV, that no local
> for existing Queues is not an issue.
> From the API doc "NoLocal - - if true, and the destination is a topic,
> inhibits the delivery of messages published by its own connection. The
> behavior for NoLocal is not specified if the destination is a queue. "
> Since we obviously create the subscription queues for each topic at
> the time of subscription, at least from a JMS pov we can easily ensure
> that we pass the no-local argument when creating the queue.
>
Yeah, I must admit I did glance at the API earlier and saw the
'Destination' signature and assumed that meant Quues were fair game,
but I didnt read the Javadoc or spec. If they arent given defined
behaviour, then its fine the way it is based on the wording (for the
BURL path that is, which does exactly what you propose based on the
broker side code I saw earlier).
>> The client currently only sends the no-local argument during queue
>> creation as you mentioned, but there is support in the protocol for
>> adding arguments to subscriptions so it could potentially be added
>> there too (The protocol actually has a no-local field on the file and
>> stream consume methods, so why it doesn't on the standard subscribe
>> method I'm not sure).
>
> I vaguely remembered something like this hence the question.
> Again speaking with Gordon I found the C++ broker does not support
> no-local being sent as an argument during subscription.
> However given the requirements around no-local for JMS I believe we
> can just get away with Topics and not worry about Queues.
>
> Rajith
Agreed (the Java broker doesnt support that just now either, I looked
before replying earlier)
>
>> Robbie
>>
>> On 13 February 2012 17:36, Rajith Attapattu <ra...@gmail.com> wrote:
>>> IIRC the no-local argument is passed on during queue-declare.
>>> But if you create a subscription with no-local=true on an existing
>>> queue how should we handle this situation ?
>>>
>>> Perhaps there is also a way to pass no-local in the arguments map when
>>> creating a subscription ?
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell
<ro...@gmail.com> wrote:
> I cross-posted this on the JIRA so I'll report it here incase anyone
> wants a discussion :)
>
>
> I think the JIRA title is perhaps a little misleading, given the
> number of tests running that show it does work to an extent.
Actually it should have been (corrected now) does not work when using
address strings.
The fix for QPID-3539 was only added to the BURL part.
> Perhaps 'doesn't work when used on queues not originally declared no-local'
> would be clearer. The BURL usage may always send the queue declare,
> but redeclaring a queue that exists wont make it no-local.
My bad, the intention of the JIRA was to address the issue of no-local
not working when using address strings.
But it seems I have unintentionally highlighted the issue of no-local
not working for existing queues.
Speaking with Gordon, it seems, at-least from a JMS POV, that no local
for existing Queues is not an issue.
>From the API doc "NoLocal - - if true, and the destination is a topic,
inhibits the delivery of messages published by its own connection. The
behavior for NoLocal is not specified if the destination is a queue. "
Since we obviously create the subscription queues for each topic at
the time of subscription, at least from a JMS pov we can easily ensure
that we pass the no-local argument when creating the queue.
> The client currently only sends the no-local argument during queue
> creation as you mentioned, but there is support in the protocol for
> adding arguments to subscriptions so it could potentially be added
> there too (The protocol actually has a no-local field on the file and
> stream consume methods, so why it doesn't on the standard subscribe
> method I'm not sure).
I vaguely remembered something like this hence the question.
Again speaking with Gordon I found the C++ broker does not support
no-local being sent as an argument during subscription.
However given the requirements around no-local for JMS I believe we
can just get away with Topics and not worry about Queues.
Rajith
> Robbie
>
> On 13 February 2012 17:36, Rajith Attapattu <ra...@gmail.com> wrote:
>> IIRC the no-local argument is passed on during queue-declare.
>> But if you create a subscription with no-local=true on an existing
>> queue how should we handle this situation ?
>>
>> Perhaps there is also a way to pass no-local in the arguments map when
>> creating a subscription ?
>>
>> Regards,
>>
>> Rajith
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: handling no-local for existing queues
Posted by Robbie Gemmell <ro...@gmail.com>.
I cross-posted this on the JIRA so I'll report it here incase anyone
wants a discussion :)
I think the JIRA title is perhaps a little misleading, given the
number of tests running that show it does work to an extent. Perhaps
'doesn't work when used on queues not originally declared no-local'
would be clearer. The BURL usage may always send the queue declare,
but redeclaring a queue that exists wont make it no-local.
The client currently only sends the no-local argument during queue
creation as you mentioned, but there is support in the protocol for
adding arguments to subscriptions so it could potentially be added
there too (The protocol actually has a no-local field on the file and
stream consume methods, so why it doesn't on the standard subscribe
method I'm not sure).
Robbie
On 13 February 2012 17:36, Rajith Attapattu <ra...@gmail.com> wrote:
> IIRC the no-local argument is passed on during queue-declare.
> But if you create a subscription with no-local=true on an existing
> queue how should we handle this situation ?
>
> Perhaps there is also a way to pass no-local in the arguments map when
> creating a subscription ?
>
> Regards,
>
> Rajith
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org