On 02/03/2012 02:45 PM, Jim Jagielski wrote:

On Feb 3, 2012, at 8:03 AM, Mladen Turk wrote:

Right, seems that's not the reason for PR52402.
Found the fix for it. The reason is the loop:

    while (s) {
        int i,j;
        proxy_balancer *balancer;
        sconf = s->module_config;
        conf = (proxy_server_conf *)ap_get_module_config(sconf,&proxy_module);

        /* adding ... */
        if (conf->bslot) {
            /* We already have shared memory storage created for this 
server_rec.
             * Skip second invocation because there are no more space left in
             * the shm so the storage->grab() will fail.
             */
            s = s->next;
            continue;
        }
        ....

Fixes the issue, although I'm not sure that's the correct solution.
Shared memory id uses vhost name for key, and think it should use
vhost:port combination instead.

However I might be wrong and the upper patch is all that's needed
if the balancer is shared between multiple server_rec's

THANKS! Let me look into this more... at 1st blush, the suggestion
of vhost:port makes sense... maybe even scheme:vhost:port.


Well actually I think that there could be multiple server_rec
for which ap_get_module_config(s->module_config,&proxy_module) will
return the same proxy_server_conf.
My patch will handle those cases (the PR52402 itself)

Think I'll commit that cause regardless of anything trying to create
already created shared memory is obvious error.


Regards
--
^TM

Reply via email to