OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/



Von: William A Rowe Jr <wrowe@xxxxxxxxxxxxx> 
Gesendet: Freitag, 20. Juli 2018 23:03
An: httpd <dev@xxxxxxxxxxxxxxxx>
Betreff: Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/


On Fri, Jul 20, 2018, 15:22 Ruediger Pluem <mailto:rpluem@xxxxxxxxxx> wrote:

BTW: We have the same load order issue issue with the following proxy modules:

mod_proxy_connect
mod_proxy_ftp
mod_proxy_http
mod_proxy_fcgi
mod_proxy_scgi
mod_proxy_fdpass
mod_proxy_ajp
mod_proxy_balancer
mod_proxy_express

> Correct. However this isn't a regression, and mod_proxy is an apparent prerequisite to any of these,
> which further and thankfully sorts first. The lbmethod providers differed in all three respects.
>

Correct, but we are little bit lucky with the sort ordering here (or was it by design from the very beginning?)
 
> It might be interesting to solve in a future enhancement release, but the number of dependencies
> likely makes this unrealistic.

This is what I stumbled across. I found it kind of weird to add an APR_DECLARE_OPTIONAL_FN for ap_proxy_balancer_get_best_worker
just after the PROXY_DECLARE for the same in mod_proxy.h. Later I understood why: We make the mod_proxy API accessible here
via 2 different ways.
I think mod_proxy is somewhat unique here as it seems to be the only module that is not always linked statically (like mod_core)
that provides a high number of functions that are consumed by "sub"-modules.
In case of other non core modules we usually encapsulate that via optional functions, provider interfaces or hooks. So probably
also in the light of mod_proxy_http2 a review should be due how we can provide this API functionality in a less load
dependent way. But I agree that it will be a huge, time consuming and disruptive (probably even unthankful) change.

Regards

Rüdiger