[
https://issues.apache.org/activemq/browse/AMQCPP-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49067#action_49067
]
roach edited comment on AMQCPP-220 at 1/30/09 2:19 PM:
-------------------------------------------------------------
It's actually not all bad. I obviously didn't think about it, but my
optimization attempt really ... wasn't.
apr_pool_destroy() won't actually free() the memory because the subpool's
allocator is inherited from the parent pool. The memory will get marked as not
in use and get re-used by a subsequent apr_pool_create_ex() call. So it's doing
what I wanted it to do in the first place. I hate it when I second-guess myself.
Thanks for getting the patch into the trunk.
was (Author: roach):
It's actually not all bad. I obviously didn't think about it, but my
optimization attempt really ... wasn't.
apr_pool_destroy() won't actually free() the memory because the subpool's
allocator is inherited from the parent pool. The memory will get marked as not
in use and get re-used by a subsequent apr_pool_create_ex() call. So it's doing
what I wanted it to do in the first place. I hate it when I second-guess myself.
> 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
> Fix For: 2.2.4, 3.0
>
> 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.
