Jim Jagielski wrote:
>
> 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->
One of the question is should we go on using scoreboard to store the
balancers and workers information or should we already add a layer to a
provider that will provide all the features we need to handle the
balancers and workers informations.
Cheers
Jean-Frederic
