[
https://issues.apache.org/activemq/browse/AMQCPP-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Roach updated AMQCPP-220:
-------------------------------
Attachment: amq.patch
Here is the patch against the current 2.2.3 tarball.
It patches:
src/main/decaf/util/concurrent/Mutex.cpp
src/main/decaf/util/concurrent/Mutex.h
It creates a subpool from the AprPool object, then uses the subpool for the
apr_thread_cond_create() call in Mutex::wait(), clearing it afterward so the
same pool memory is re-used on subsequent calls.
This has now been tested for over 24 hours in our production environment,
processing ~ 40 million messages. The memory utilization is now constant where
previously it was growing several megabytes per hour.
> Memory leak in activemq-cpp
> ---------------------------
>
> Key: AMQCPP-220
> URL: https://issues.apache.org/activemq/browse/AMQCPP-220
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Components: CMS Impl
> Affects Versions: 2.2.3
> Environment: Solaris 10 x86
> GCC (g++) 3.4.6 (from www.sunfreeware.com)
> APR 1.3.3
> APR-util 1.3.4
> Reporter: Brian Roach
> Assignee: Timothy Bish
> Priority: Critical
> Attachments: amq.patch
>
>
> The API leaks ~ 2MB of memory for every 1 million messages consumed.
> The example consumer in activemq-cpp-2.2.3-src/src/examples/consumers can be
> used as a test bed, it exhibits the behavior.
> It's even worse if you are not using the consumer->setMessageListener( )
> method and are instead directly using the consumer->receive() method in your
> own loop. I dont' have hard numbers but it is somewhere around ten-fold.
> We have an application which is processing ~ 40 million messages per day, and
> will keep growing until the box runs out of memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
