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
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
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'
On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell
robbie.gemm...@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
On 13 February 2012 19:42, Rajith Attapattu rajit...@gmail.com wrote:
On Mon, Feb 13, 2012 at 12:53 PM, Robbie Gemmell
robbie.gemm...@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
*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
On 13 February 2012 21:59, Rob Godfrey rob.j.godf...@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
One could argue that the no-local should be treated the same way as
selectors on a durable subscription - that is that the no-localness
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
