On 09/10/2013 06:00 AM, sparso wrote:
Thanks for the info, I can confirm it is indeed due to failover and message
audit.

With the following url, the example application remains on 4% CPU and 15 meg
of memory:

"failover:(tcp://localhost:61616)?connection.checkForDuplicates=false"

Without the "checkForDuplicates=false" the cpu and memory usage grows
constantly. I eventually stopped it at 100% CPU and 340 meg of memory.

Valgrind suggested that the leak was in ConnectionAudit.cpp:100. I added the
following debug:

                 try {
                     audit = this->impl->destinations.get(destination);
                 } catch (NoSuchElementException& ex) {
                     audit.reset(new ActiveMQMessageAudit(auditDepth,
auditMaximumProducerNumber));
                     this->impl->destinations.put(destination, audit);
                     std::cout << "New destination audit: " <<
destination->toString()
                               << ", size: " <<
this->impl->destinations.keySet().size() << std::endl;
                 }

...and it prints...

Sent message #410 from thread 140736021874568
New destination audit: queue://TEST.FOO, size: 410
Message #410 Received: Hello world! from thread 140736021874568
Sent message #411 from thread 140736021874568
New destination audit: queue://TEST.FOO, size: 411
Message #411 Received: Hello world! from thread 140736021874568

So the size of the destinations map keeps increasing. It seems to think
every message has a new destination, but this is not the case. It's just the
example code in main.cpp which creates the TEST.FOO destination and sends
messages to it in a loop.





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Memory-leak-in-activemq-cpp-activemq-cpp-library-3-7-1-tp4671248p4671331.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Sounds like there's a bug there then, can you open a Jira issue and maybe see if you can add a test case to the ConnectionAuditTest in ./src/test/activemq/core that triggers Valgrind to complain, that would help to ensure that future releases can be checked for this leak.

--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Reply via email to