Kevin Smith wrote:
Attached is my attempt at fixing this problem. There are, no doubt,
better ways to do this. This is just the way I hacked to fix the
fall-over-with-three-clients problem I was having.
Thanks, Kevin!
My patch does three things:
1) Modifies the APRPool class to use alloc/free semantics for APR memory
pools. Each time a caller calls APRPool::get() they'll their own pool
reference. I've fixed up all the call sites I can find to also call
APRPool::free() at the appropriate time.
Yes, thats what I did originally as well.
2) Caches freed APR memory pools in a STL stack. This cuts down on the
number of memory pools created overall.
Nice idea.
3) As a result of doing #1 and #2 I've introduced a guard mutex around
APRPool::get() and APRPool::free(). This is to prevent concurrent access
to the memory pool cache. If it's too heavyweight, the mutex along with
the caching mechanism could be removed entirely.
Like I said before, my C++ is very rusty so I make no guarantees about
code correctness or quality. I've fixed the leaks I could find (and
understand) from valgrind so I _think_ this isn't any leakier than the
code was before my patch.
I've run a mini-stress test (10 concurrent clients sending messages via
a topic exchange) multiple times and haven't been able to get the broker
to fall over. Memory usage seems pretty stable once the broker is up and
all clients have connected.
Thanks again for sending in the patch. Andrew is working on replacing
apr mutexes etc with pthreads. However this change might still be a
useful complement to that covering some of the other apr objects?
