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

[C++ broker] Active HA broker memory leak when creating&unsubscribing from an autoDel queue

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: qpid-cpp-0.34
    • Fix Version/s: None
    • Component/s: C++ Broker
    • Labels:
      None

      Description

      Having a consumer that (in a loop):

      • creates an autoDelete queue
      • subscribes to it
      • unsubscribes
        against a HA cluster, primary broker memory consumption grows over the time.

      Steps to Reproduce:
      1. Start 3 brokers in a HA cluster (mine reproducer uses options:

      qpidd --port=5672 --store-dir=_5672 --log-to-file=qpidd.5672.log --data-dir=_5672 --auth=no --log-to-stderr=no --ha-cluster=yes --ha-brokers-url=localhost:5672,localhost:5673,localhost:5674 --ha-replicate=all

      )

      2. Run simple qpid-receive in a loop:
      while true; do
      qpid-receive -a "autoDelQueue; {create:always, node:{ x-declare:

      {auto-delete:True}

      }}"
      sleep 0.1
      done

      3. Monitor memory usage of primary broker.

      Observations from variants of reproducer:

      • standalone broker does not exhibit that mem.leak
      • even standalone broker in HA cluster does not - backup brokers are mandatory for the leak
      • anyway, replicator bridge queues on primary stand almost everytime empty, no bursts of messages occur there.
      • just the primary broker is affected, backups are OK
      • amount of leaked memory does not depend on number of backups (very similar mem.usage when having 1,2 or 4 backups)
      • valgrind does not show any leaked or excessive "still reachable" memory, even after 1 hour test where memory consumption of valgrind grew evidently
      • curiously, every running "qpid-stat -q" causes additional memory is leaked - maybe due to the fact it uses auxiliary autoDel queue as well (but just one while the leak is much bigger)?
      • bug not is present in 0.30
      • --ha-replicate=all is crucial, even --ha-replication=configuration does not trigger the leak
      • adding --enable-qmf2=no prevents most the leak - memory still grows (sic!) but evidently slower

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              pmoravec Pavel Moravec
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: