Are the changes that Andrew is working on aimed at the M2 release?
Cheers, Rob On 22/05/07, Gordon Sim <[EMAIL PROTECTED]> wrote:
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?
