Uploaded image for project: 'Qpid'
  1. Qpid
  2. QPID-6740

[C++ broker, Python client] Message not delivered after "empty" exception

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 0.32
    • Fix Version/s: None
    • Component/s: C++ Broker, Python Client
    • Labels:
      None
    • Environment:

      CentOS 7.1
      qpid (C++) 0.32, qpid-python 0.32

      Description

      If this is not a bug, the documentation might need an update, as I'm not aware of what I did wrong.

      Here is a test case, you will need two ipython consoles.

      console 1
      from qpid.messaging import Connection
      
      session = Connection.establish('amqp://127.0.0.1').session()
      sender = session.sender(
          'mytestqueue; {create: always, node: {durable: True, type: queue}}')
      cleaner = session.receiver('mytestqueue')
      cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
      

      (The receiver is named cleaner because it is only supposed to "free" the queue from any old messages.)

      console 2
      from qpid.messaging import Connection
      
      session = Connection.establish('amqp://127.0.0.1').session()
      receiver = session.receiver('mytestqueue')
      receiver.fetch()
      

      Back to the first console:

      console 1
      sender.send({'msg': 'test'})
      

      This message does not arrive at the second console. The receiver.fetch() still blocks.

      I have the following observations about this situation:

      1. One workaround is to call cleaner.close(), the blocking receiver will immediately return the message.
      2. Another workaround is to specify a time-out in the receiver.fetch() call (test it with timeout=60). The message will be returned, though only at the end of the time-out!
      3. Sending a second message will result in immediate delivery of the first message.
      4. Once the situation is unblocked, you have to start anew in order to experience the blocking situation again. Don't forget to call session.acknowledge() before ending the console 2, or use a fresh queue.
      5. The problem only manifests itself when receiver.fetch() starts before the message is sent.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              vhorvath Viktor Horvath
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: