On Nov 27, 2007, at 10:16 AM, jean-frederic clere wrote:

Jeff Trawick wrote:
On Nov 27, 2007 8:47 AM, Plüm, Rüdiger, VF-Group
<[EMAIL PROTECTED]> wrote:

-----Ursprüngliche Nachricht-----
Von: Jeff Trawick
Gesendet: Dienstag, 27. November 2007 14:21
An: dev@httpd.apache.org
Betreff: memory leak in 2.2.x balancer?

looks like a leak to me; what do you think?

Index: modules/proxy/mod_proxy_balancer.c
===================================================================
--- modules/proxy/mod_proxy_balancer.c  (revision 598305)
+++ modules/proxy/mod_proxy_balancer.c  (working copy)
@@ -654,7 +654,7 @@
         const char *val;
         if ((val = apr_table_get(params, "ss"))) {
             if (strlen(val))
-                bsel->sticky = apr_pstrdup(conf->pool, val);
+                bsel->sticky = apr_pstrdup(r->pool, val);
             else
                 bsel->sticky = NULL;
         }

trunk looks much different here.  Does anyone plan to backport the
larger changes to 2.2.x in the near term, or should we go for this
tweak?
This is no leak as if it were possible to adjust the balancer settings via the balancer manager their memory would need to be taken from a long living pool or more precise from the shared memory. This is not implemented now. So it makes no sense to adjust the balancer settings via the balancer manager. For this reason this possibility was removed from trunk. So far no one has
found the energy to propose a clear backport of this change.
So if someone find the energy soon, fine. If not please leave everything as it
is as we face segfaults otherwise.

Thanks for the explanation.  I'll try to find time to find a patch to
remove this misfeature from the 2.2.x branch.


The only thing that can be changed is what is stored in the scoreboard
the rest may work (threaded only) or won't work (prefork).


well, what happens is that it's not universal among all balancers
and so depending on which process (and therefore which threads
in worker) gets the request, it could be operating under
different conditions :)

It's too much work with the existing 2.2 architecture to fix
this, but it is viable for 2.4->

Reply via email to