After further investigation, no memory leak situation was identified.
** Changed in: rabbitmq-server (Ubuntu)
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/119738
** Attachment added: "rabbitmq-memleak.png"
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1197380/+attachment/3738568/+files/rabbitmq-memleak.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchp
Indeed, my test statement was wrong.
I now have updated the test statement & ran another set of tests both on
Precise (2.7.1) and Saucy (3.1.3). Both test ran for 14 hours. Here is
an outline of the memory usage in both cases:
DistroVersionMem UsedMem Free
===
** Changed in: rabbitmq-server (Ubuntu)
Assignee: (unassigned) => Louis Bouchard (louis-bouchard)
** Changed in: rabbitmq-server (Ubuntu)
Status: New => In Progress
** Description changed:
rabbitmq-server seems to be leaking memory. This has been tested with
Precise, Raring and S
Umm, with the shell fragment posted, you have the receiver started
outside the "while true" loop. Therefore the shell will never start the
receiver, and messages back up inside RabbitMQ until memory is
exhausted.
You can verify this with "rabbitmqctl list_queues" or the management
plugin web UI.
reproducer script : queue_send.py
** Attachment added: "queue_send.py"
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1197380/+attachment/3723024/+files/queue_send.py
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Reproducer script : queue_receive.py
** Attachment added: "queue_receive.py"
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1197380/+attachment/3723025/+files/queue_receive.py
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
