Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-5198

[LTS] Qpid Proton C++ client does not work with filtered queues

XMLWordPrintable

    • False
    • False
    • Undefined
    • Hide

      Pre-requisites: Linux system with Qpid-Proton runtime adn development libraries, and GCC and associated tools. installed.

      1. Unpack the attached 02936878.zip
      2. Install AMQ 7.8.1 Create a new instance. Copy all the XML files from the attached zipfile into the etc/ directory. There don't need to be this many files, but I've made this reproducer by cutting down the customer's very complex installation into a simple one, so the same files exist.
      3. Start the broker. Verify (e.g., using Hawtio) that the address "foo" exists, and that it has two queues "foo/foo--temp" and "foo/foo--filtered".
      4. Compile the Proton test consumer:

      $ g++ -o rhlprotontest RHLProtonTest.cpp -lqpid-proton-cpp

      5. Run the test consumer.

      ./rhlprotontest localhost:61616 foo--filtered foo foo

      NB: user "foo" has "read" persmissions on the "foo" address, but no other permissions.

      6. Note that the connection fails:

      "User: foo does not have permission='CREATE_DURABLE_QUEUE' for queue foo/foo--filtered on address foo"

      7. Notice that the queue "foo/foo-filtered" has disappeared from Hawtio, and from the output of "artemis queue stat"

      8. Run the consumer again, on the "temp" queue:

      ./rhlprotontest localhost:61616 foo--temp foo foo

      9. Note that the consumer connects correctly.

       

      Show
      Pre-requisites: Linux system with Qpid-Proton runtime adn development libraries, and GCC and associated tools. installed. 1. Unpack the attached 02936878.zip 2. Install AMQ 7.8.1 Create a new instance. Copy all the XML files from the attached zipfile into the etc/ directory. There don't need to be this many files, but I've made this reproducer by cutting down the customer's very complex installation into a simple one, so the same files exist. 3. Start the broker. Verify (e.g., using Hawtio) that the address "foo" exists, and that it has two queues "foo/foo--temp" and "foo/foo--filtered". 4. Compile the Proton test consumer: $ g++ -o rhlprotontest RHLProtonTest.cpp -lqpid-proton-cpp 5. Run the test consumer. ./rhlprotontest localhost:61616 foo--filtered foo foo NB: user "foo" has "read" persmissions on the "foo" address, but no other permissions. 6. Note that the connection fails: "User: foo does not have permission='CREATE_DURABLE_QUEUE' for queue foo/foo--filtered on address foo" 7. Notice that the queue "foo/foo-filtered" has disappeared from Hawtio, and from the output of "artemis queue stat" 8. Run the consumer again, on the "temp" queue: ./rhlprotontest localhost:61616 foo--temp foo foo 9. Note that the consumer connects correctly.  

      This bug arises is a somewhat obscure combination of circumstances; however, it is a genuine customer problem that is delaying implementation. It only affects C++ clients – a Java client can consume from the affected addresses without problems.

      The problem arises when an address has a named queue defined with a filter, like this:

      <queue name="foo/foo--filtered" purge-on-no-consumers="false" >
        <filter string="foo='BAR'"/>
        <durable>true</durable>
</queue>

      Without the filter, everything is fine. It is important that the consumer client does not have rights to auto-create queues.

      When a C++ client tries to connect as a consumer to "foo/foo–filtered", it fails, with a security exception. Looking at the console shows that the queue no longer exists, although the address is still present, as are other queues defined for the same address.

      Connecting the consumer to a queue in the same address, but without the filter, works fine.

      It isn't clear to me whether the primary failure is the apparent lack of permissions, or the disappearing queue. If the queue disappears, then the client will get a permissions error, because it doesn't have rights to create the queue. However, it's also possible (I guess) that the primary problem is the apparent lack of permissions, and the queue removal is a consequence of that.

      Once the C++ has caused the queue to disappear, it becomes unavailable for other clients because they, also, do not have permissions to create the queue.

       

              rhn-support-jbertram Justin Bertram
              rhn-support-kboone Kevin Boone
              Roman Vais Roman Vais (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: