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

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: qpid-cpp-0.34
• Component/s: C++ Broker
• External issue ID: https://bugzilla.redhat.com/show_bug.cgi?id=1350023
• Assignee: Unassigned
• Reporter: Pavel Moravec
• Created: 27/Jun/16 20:47
• Updated: 27/Jun/16 20:47

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