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

[Ruediger Pluem <rp...@apache.org>]

On 07/20/2018 09:27 PM, rpluem@apache.org wrote:
> Author: rpluem
> Date: Fri Jul 20 19:27:31 2018
> New Revision: 1836381
> 
> URL: http://svn.apache.org/viewvc?rev=1836381&view=rev
> Log:
> * mod_proxy: Remove load order and link dependency between mod_lbmethod_*
>   modules and mod_proxy by providing mod_proxy's ap_proxy_balancer_get_best_worker
>   as an optional function.
> 
> PR: 62557
> 

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

Regards

Rüdiger

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

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

Von: William A Rowe Jr <wr...@rowe-clan.net> 
Gesendet: Freitag, 20. Juli 2018 23:03
An: httpd <de...@httpd.apache.org>
Betreff: Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/


On Fri, Jul 20, 2018, 15:22 Ruediger Pluem <ma...@apache.org> 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

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

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Jul 20, 2018, 15:22 Ruediger Pluem <rp...@apache.org> 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.

It might be interesting to solve in a future enhancement release, but the
number of dependencies likely makes this unrealistic.