httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <>
Subject Re: svn commit: r573264 - /httpd/httpd/trunk/include/scoreboard.h
Date Mon, 10 Sep 2007 14:13:27 GMT
Jim Jagielski wrote:
> On Sep 10, 2007, at 8:24 AM, jean-frederic clere wrote:
>> Jim Jagielski wrote:
>>> On Sep 10, 2007, at 6:37 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>> For example what about adding:
>>>>> static APR_OPTIONAL_FN_TYPE(ap_proxy_lb_worker_size)
>>>>> *proxy_lb_worker_size;
>>>>> and use a void * in scoreboard and an int for the size?
>>>> For me this sounds fine, but I would guess that Jim doesn't like
>>>> the void * idea in the scoreboard.
>>> I don't mind it at all, if we use it because we don't know
>>> what will be stored away or because we may use the storage
>>> differently at different times. But this is never the
>>> case. lb_score always is proxy_worker_stat.
>> My point goes with the comment in the code:
>> +++
>> /* stuff which is lb specific */
>> typedef proxy_worker_stat lb_score;
>> +++
>> A custom balancer may have a different proxy_worker_stat, so in fact
>> only modules/proxy/mod_proxy_balancer.c should know what the
>> proxy_worker_stat structure contains.
> I'm not sure what you mean. mod_proxy does, in child_init,
> the calls to create those scoreboard entries. It does
> so via ap_proxy_initialize_worker_share(). No matter
> what, the ->s is set to:
>    worker->s = (proxy_worker_stat *)score;

Well below that, the lines:
       if (worker->route) {
        strcpy(worker->s->route, worker->route);
shows cleary the problem.

> If some other struct is used then lots and lots of
> other code needs to be changed to make lb_score and
> mod_proxy *really* opaque to each other.

Not so much because some routines in proxy_util could be moved to
mod_proxy_balancer.c (They are used only there) for the others adding a
provider may be the way to go.

> Or are you suggesting that some other "balancer"
> which completely bypasses mod_proxy (and, in fact,
> replaces mod_proxy) could be using that scoreboard
> entry?

Well such a tool could use its own shared memory but yes making lb_score
opaque in scoreboard.c will allow to write such modules.

> Again, as I said, my main issues were that (1) we
> were trying to pretend that lb_score != proxy_worker_stat
> when, in fact, they are and, if anyone tried to use
> it otherwise, things would break nastily. So why the
> weird indirection? Not elegant at all :) 

Agreed I had problem with that while experimenting in
httpd-proxy-scoreboard. It is "hard" to do that in mod_proxy but easy to
 do between mod_proxy and the scoreboard so why not doing it?

> and (2)
> I can't see creating 1k chunks for each entry when
> each one really only needs ~160-200 bytes (depending
> on int and other sizes) and (3) if, for some reason,
> proxy_worker_stat does increase, we need to always
> make sure that things sync up enough with the entry
> in scoreboard.h that we really have enough space.
> And once again, the *real* fix is changing our usage
> and allocation of the scoreboard, something set for
> 3.0. If people want that for 2.4, then cool.

One thing is what we store another thing is where we store it.
We are discussing what we store ;-)




View raw message