[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:


> 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.