Pavel Moravec created QPID-7325:
-----------------------------------

             Summary: [C++ broker] Active HA broker memory leak when 
creating&unsubscribing from an autoDel queue
                 Key: QPID-7325
                 URL: https://issues.apache.org/jira/browse/QPID-7325
             Project: Qpid
          Issue Type: Bug
          Components: C++ Broker
    Affects Versions: qpid-cpp-0.34
            Reporter: Pavel Moravec


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




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to