Qpid
  1. Qpid
  2. QPID-2482

Topic Exchange can duplicate messages.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.7
    • Component/s: C++ Broker
    • Labels:
      None
    • Environment:

      Linux

      Description

      As per Gordon's description:

      If a given queue is bound to a topic exchange with multiple bindings, a message sent to that exchange will result in a copy being enqueued for each binding that matches. This is incorrect - each message should be enqueued once if there is any binding to the queue that matches it.

      Steps to Reproduce:
      1. create queue
      2. bind it to amq.topic with two distinct bindings (e.g. red.* and *.herring)
      3. send amq.topic a message whose routing key matches both patterns (e.g. "red.herring")
      4. check the queue

      Actual results:

      The message is enqueued on the queue twice.

      Expected results:

      The message should only be enqueued on the queue once.

        Activity

        Hide
        Ken Giusti added a comment -

        Ensure only one instance of a given queue appears on the routing list.

        Show
        Ken Giusti added a comment - Ensure only one instance of a given queue appears on the routing list.
        Hide
        Emmanuel Bourg added a comment -

        The same issue exists with the Java broker (version 0.6). The examples in org.apache.qpid.example.amqpexample.pubsub exhibit this behavior.

        Show
        Emmanuel Bourg added a comment - The same issue exists with the Java broker (version 0.6). The examples in org.apache.qpid.example.amqpexample.pubsub exhibit this behavior.
        Hide
        Ken Giusti added a comment -

        Good catch, Emmanuel. I'd like to open up a new jira to track the java issue separately. I'm not very experienced with that implementation.

        thanks,

        -K

        Show
        Ken Giusti added a comment - Good catch, Emmanuel. I'd like to open up a new jira to track the java issue separately. I'm not very experienced with that implementation. thanks, -K
        Hide
        Rob Godfrey added a comment -

        Emmanuel - can you give the explicit steps you used to reproduce this behaviour in the Java Broker...

        Looking at the code for the TopicExchange it should already eliminate duplicate queues (the queues are collated in a Set)

        Show
        Rob Godfrey added a comment - Emmanuel - can you give the explicit steps you used to reproduce this behaviour in the Java Broker... Looking at the code for the TopicExchange it should already eliminate duplicate queues (the queues are collated in a Set)
        Hide
        Robbie Gemmell added a comment -

        I too looked at the code and didnt see how this could occur on the Java broker, and having tried the example was not able to reproduce any problem with the example.

        There are 4 queues created by the TopicListener in the example, bound to amp.topic with a specific binding key:
        listener.prepareQueue(session,"usa", "usa.#");
        listener.prepareQueue(session,"europe", "europe.#");
        listener.prepareQueue(session,"news", "#.news");
        listener.prepareQueue(session,"weather", "#.weather");

        The TopicPublisher in the example then sends 4 sets of messages whereby the topic each message is sent to matches exactly two of the bindings for the 4 queues above, eg 'usa.#' and '#.news' in the first set of messages sent:
        publisher.publishMessages(session, "usa.news");
        publisher.publishMessages(session, "usa.weather");
        publisher.publishMessages(session, "europe.news");
        publisher.publishMessages(session, "europe.weather");

        The log output from the listener shows it recieving twice as many times as there are messages sent, reflecting that 2 queues match each message and sent. I dont see any indication that the same queue recieved the same message twice.

        Show
        Robbie Gemmell added a comment - I too looked at the code and didnt see how this could occur on the Java broker, and having tried the example was not able to reproduce any problem with the example. There are 4 queues created by the TopicListener in the example, bound to amp.topic with a specific binding key: listener.prepareQueue(session,"usa", "usa.#"); listener.prepareQueue(session,"europe", "europe.#"); listener.prepareQueue(session,"news", "#.news"); listener.prepareQueue(session,"weather", "#.weather"); The TopicPublisher in the example then sends 4 sets of messages whereby the topic each message is sent to matches exactly two of the bindings for the 4 queues above, eg 'usa.#' and '#.news' in the first set of messages sent: publisher.publishMessages(session, "usa.news"); publisher.publishMessages(session, "usa.weather"); publisher.publishMessages(session, "europe.news"); publisher.publishMessages(session, "europe.weather"); The log output from the listener shows it recieving twice as many times as there are messages sent, reflecting that 2 queues match each message and sent. I dont see any indication that the same queue recieved the same message twice.
        Hide
        Emmanuel Bourg added a comment -

        Sorry for the false report, I misunderstood the behavior of the example. I saw the messages twice and assumed that was the same issue reported here. But in this case there is one queue with several bindings, whereas the example uses several queues with only one binding.

        Maybe changing the example to use only one queue would avoid the confusion.

        Show
        Emmanuel Bourg added a comment - Sorry for the false report, I misunderstood the behavior of the example. I saw the messages twice and assumed that was the same issue reported here. But in this case there is one queue with several bindings, whereas the example uses several queues with only one binding. Maybe changing the example to use only one queue would avoid the confusion.

          People

          • Assignee:
            Ken Giusti
            Reporter:
            Ken Giusti
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development