httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject RE: PR 58267: Regression in 2.2.31 caused by r1680920
Date Tue, 25 Aug 2015 08:48:18 GMT
I think the current state of 2.2.31 breaks existing 2.2.x configuration prior to 2.2.31.
Prior to 2.2.31 you could do the following:

<Proxy Balancer://proxy1>
BalancerMember ajp://127.0.0.1:7001
BalancerMember ajp://127.0.0.2:7002
</Proxy>

<virtualhost *:80>
ProxyPass / balancer://proxy1/
</virtualhost>

<virtualhost 127.0.0.1:8080>

<Location /bmanager>
   sethandler balancer-manager
</Location>

</virtualhost>

With this configuration you could provide your reverse proxy to the outside world while having
the
balancermanager managing the balancer only listening to localhost. This is not possible any
longer with 2.2.31
as the worker->s is now different in each virtualhost whereas before it was the same as
the worker->id was used
to identify the scoreboard slot.
The patches proposed so far would not change this. I think in order to revert to the old behaviour
we need to
store with each worker in which server_rec context it was created. e.g. adding a const char
* field to the worker that would be filled with
server->server_hostname. Then we could use this value for creating the md5.

Regards

Rüdiger

> -----Original Message-----
> From: Jan Kaluža [mailto:jkaluza@redhat.com]
> Sent: Dienstag, 25. August 2015 10:23
> To: dev@httpd.apache.org
> Subject: Re: PR 58267: Regression in 2.2.31 caused by r1680920
> 
> On 08/24/2015 11:12 PM, Yann Ylavic wrote:
> > On Mon, Aug 24, 2015 at 5:51 PM, Yann Ylavic <ylavic.dev@gmail.com>
> wrote:
> >>
> >> On Mon, Aug 24, 2015 at 4:47 PM, Jan Kaluža <jkaluza@redhat.com> wrote:
> >>>
> >>> 2) Increment proxy_lb_workers according to number of workers in
> balancer
> >>> when using "ProxyPass /foobar/ Balancer://foobar/" in the VirtualHost.
> The
> >>> scoreboard would have right size and ap_proxy_set_scoreboard_lb would
> not
> >>> fail then.
> >>
> >> I think we can do this quite easily in merge_proxy_config(), by
> >> incrementing proxy_lb_workers for each base->balancers->workers. I did
> >> not test it yet though.
> >
> > I tested the below which seems to work.
> 
> Hm, this reserves the slots in scoreboard even when the balancers are
> not used in the virtualhost, or am I wrong?
> 
> I originally thought about increasing proxy_lb_workers only when they
> are used in the ProxyPass* in the vhost.
> 
> > Index: modules/proxy/mod_proxy.c
> > ===================================================================
> > --- modules/proxy/mod_proxy.c    (revision 1697358)
> > +++ modules/proxy/mod_proxy.c    (working copy)
> > @@ -1135,6 +1135,7 @@ static void * create_proxy_config(apr_pool_t *p, s
> >
> >   static void * merge_proxy_config(apr_pool_t *p, void *basev, void
> *overridesv)
> >   {
> > +    int i;
> >       proxy_server_conf *ps = apr_pcalloc(p, sizeof(proxy_server_conf));
> >       proxy_server_conf *base = (proxy_server_conf *) basev;
> >       proxy_server_conf *overrides = (proxy_server_conf *) overridesv;
> > @@ -1147,6 +1148,13 @@ static void * merge_proxy_config(apr_pool_t *p,
> vo
> >       ps->allowed_connect_ports = apr_array_append(p,
> > base->allowed_connect_ports, overrides->allowed_connect_ports);
> >       ps->workers = apr_array_append(p, base->workers, overrides-
> >workers);
> >       ps->balancers = apr_array_append(p, base->balancers, overrides-
> >balancers);
> > +    /* The balancers inherited from base don't have their members
> reserved on
> > +     * the scorebord_lb for this server, account for them now.
> > +     */
> > +    for (i = 0; i < base->balancers->nelts; ++i) {
> > +        proxy_balancer *balancer = (proxy_balancer *)base->balancers-
> >elts + i;
> > +        proxy_lb_workers += balancer->workers->nelts;
> > +    }
> >       ps->forward = overrides->forward ? overrides->forward : base-
> >forward;
> >       ps->reverse = overrides->reverse ? overrides->reverse : base-
> >reverse;
> >
> > --
> >
> > Please note that since all the workers would really be accounted in
> > the scoreboard, configurations like the one of PR 58267 (with
> > inherited balancers) would also need bigger SHMs (but no more) than
> > currently...
> >
> > WDYT?
> >
> 
> Regards,
> Jan Kaluza
> 

Mime
View raw message