Qpid
  1. Qpid
  2. QPID-3836

no-local does not work for Qpid 0-10 JMS client when using address strings

    Details

      Description

      If no-local is set to true when create a consumer or a durable subscriber, messages published by the same connection should not be seen by this consumer.
      Currently due to a bug no-local is not passed correctly when creating the subscription queue.
      All though this works for Topics and Queues created when this information is available, not sure how this should be handled when subscribing to an already existing queue.

      AKAIK the no-local argument is passed on during queue-declare. Perhaps there is also a way to pass this on when creating a subscription ?
      (I will update the description when I find the answer to the above question).

        Activity

        Hide
        Rajith Attapattu added a comment -

        The fix provided in QPID-3539 only works for the BURL format. This format always declares a queue, so the above issue does not arise.

        Show
        Rajith Attapattu added a comment - The fix provided in QPID-3539 only works for the BURL format. This format always declares a queue, so the above issue does not arise.
        Hide
        Robbie Gemmell added a comment -

        I think the 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)

        Show
        Robbie Gemmell added a comment - I think the 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)

          People

          • Assignee:
            Rajith Attapattu
            Reporter:
            Rajith Attapattu
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development