Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The mediocre talent pool in this community doesn’t mind the code
duplication of having many different form data parsers inside a common code
base because, really, collaboration and common cause is not your thing.

So live it up with the user base while they ponder your architectural
rationales like this guy does:

https://stackoverflow.com/questions/60281807/get-post-request-body-and-decode-using-mod-lua-apache-http-2-4



Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 8:47 PM Joe Schaefer  wrote:

> Stupid shit like this is everyone's problem:
>
> https://www.tenable.com/plugins/nessus/161454
>
> Hating me for solving it cleanly is par for the course for the current
> httpd committer community.
>
> On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:
>
>> Back in the day, httpd was a celebrated integration point for dozens of
>> apache projects. Literally the flagship of the organization.
>>
>> It's also why people were judicious about what to include in core, versus
>> codebases remaining elsewhere in the org as third party modules.
>>
>> Of course at this point, there's no good reason to hook a dynamic
>> language into core in a non-thread-safe way.  Yet mod_lua exists.
>> If there's no good reason to hook a thread-safe httpd-specific HTML form
>> parser technology into the mix, what is mod_dav doing in here?
>>
>> The obvious answer is because peevishness rules the day at Apache.  Very
>> Important People's pet projects have staying power, not because users
>> demand it, but because the personalities behind them would give you serious
>> shit for discarding the module on a whim.
>>
>> All I ask for is to be able to bow out and never return to this group
>> again.
>>
>>
>>
>> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>>
>>> The proof is in the pudding, as it were.
>>>
>>> There's prima facia evidence in this very thread that he lied about ever
>>> running the test suite for apreq, because Joe wouldn't have had to patch it
>>> for him 8 months later had he ever bothered in the first place.
>>>
>>> But when everyone around you is no better than that, there's
>>> participation trophies for all of you!
>>>
>>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>>
 > And because you are such a prima donna Yann

 Yann is an amazing programmer and super easy to work with. Maybe it's
 hard to tell from the backseat.

>>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Stupid shit like this is everyone's problem:

https://www.tenable.com/plugins/nessus/161454

Hating me for solving it cleanly is par for the course for the current
httpd committer community.

On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer  wrote:

> Back in the day, httpd was a celebrated integration point for dozens of
> apache projects. Literally the flagship of the organization.
>
> It's also why people were judicious about what to include in core, versus
> codebases remaining elsewhere in the org as third party modules.
>
> Of course at this point, there's no good reason to hook a dynamic language
> into core in a non-thread-safe way.  Yet mod_lua exists.
> If there's no good reason to hook a thread-safe httpd-specific HTML form
> parser technology into the mix, what is mod_dav doing in here?
>
> The obvious answer is because peevishness rules the day at Apache.  Very
> Important People's pet projects have staying power, not because users
> demand it, but because the personalities behind them would give you serious
> shit for discarding the module on a whim.
>
> All I ask for is to be able to bow out and never return to this group
> again.
>
>
>
> On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:
>
>> The proof is in the pudding, as it were.
>>
>> There's prima facia evidence in this very thread that he lied about ever
>> running the test suite for apreq, because Joe wouldn't have had to patch it
>> for him 8 months later had he ever bothered in the first place.
>>
>> But when everyone around you is no better than that, there's
>> participation trophies for all of you!
>>
>> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>>
>>> > And because you are such a prima donna Yann
>>>
>>> Yann is an amazing programmer and super easy to work with. Maybe it's
>>> hard to tell from the backseat.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Back in the day, httpd was a celebrated integration point for dozens of
apache projects. Literally the flagship of the organization.

It's also why people were judicious about what to include in core, versus
codebases remaining elsewhere in the org as third party modules.

Of course at this point, there's no good reason to hook a dynamic language
into core in a non-thread-safe way.  Yet mod_lua exists.
If there's no good reason to hook a thread-safe httpd-specific HTML form
parser technology into the mix, what is mod_dav doing in here?

The obvious answer is because peevishness rules the day at Apache.  Very
Important People's pet projects have staying power, not because users
demand it, but because the personalities behind them would give you serious
shit for discarding the module on a whim.

All I ask for is to be able to bow out and never return to this group again.



On Thu, Feb 15, 2024 at 8:20 PM Joe Schaefer  wrote:

> The proof is in the pudding, as it were.
>
> There's prima facia evidence in this very thread that he lied about ever
> running the test suite for apreq, because Joe wouldn't have had to patch it
> for him 8 months later had he ever bothered in the first place.
>
> But when everyone around you is no better than that, there's participation
> trophies for all of you!
>
> On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:
>
>> > And because you are such a prima donna Yann
>>
>> Yann is an amazing programmer and super easy to work with. Maybe it's
>> hard to tell from the backseat.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The proof is in the pudding, as it were.

There's prima facia evidence in this very thread that he lied about ever
running the test suite for apreq, because Joe wouldn't have had to patch it
for him 8 months later had he ever bothered in the first place.

But when everyone around you is no better than that, there's participation
trophies for all of you!

On Thu, Feb 15, 2024 at 8:17 PM Eric Covener  wrote:

> > And because you are such a prima donna Yann
>
> Yann is an amazing programmer and super easy to work with. Maybe it's hard
> to tell from the backseat.
>

Re: release apreq 2.18 and mothball the project

[Eric Covener]

> And because you are such a prima donna Yann

Yann is an amazing programmer and super easy to work with. Maybe it's hard
to tell from the backseat.

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

 The nightmare scenario is when you try to support HTTP/3 when you can’t
even support an HTML form parser.

Have an appropriate amount of fun. Popcorn is popping.

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 7:36 PM Joe Schaefer  wrote:

> The reason the QA around httpd is so lousy lately is because none of you
> actually dogfood the software professionally, because no Fortune 500
> employer would be caught dead running httpd over nginx in the cloud.
>
> That historically lackadaisical approach to CI has no business persisting
> now that you are on GitHub.
>
> And yet it persists.
>
> It also is why you guinea pig your user base instead of respecting them,
> because you aren’t a part of that community any more.
>
> And it shows with each new dud delivered to the apreq user base over the
> past decade.
>
> So let’s end this fiasco ASAP.
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:
>
>> Keep your tone policing off list wise guy. If you have something of
>> substance to offer to your colleagues other than defensive posturing, let’s
>> have it.
>>
>> Like all these vacuous bug reports missing from the issue tracker about
>> apreq, that you rumor mongers like to scare people with.
>>
>> Joe Schaefer, Ph.D.
>> 
>> Orion - The Enterprise Jamstack Wiki
>> 
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>>
 Nobody gives a flying f what you released from trunk. I personally will
 be dead and buried before you release httpd 3.0.  So like you I don’t give
 a damned what you do with it.

 I just want the warfare against existing libapreq2 users to cease and
 desist.

 If there are known vulnerabilities in the existing codebase, you have a
 professional obligation to report them to the security team, who have
 assured me they will send them my way for proper handling by a competent
 engineer.

 None have been forthcoming, so that’s reason to release 2.18 as-is and
 mothball the subproject so we need not deal with each other again over it.

 Thanks

 Joe Schaefer, Ph.D.
 
 Orion - The Enterprise Jamstack Wiki
 
 
 954.253.3732 




 On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
> wrote:
>
>> Twenty years in core, with one bug to fix.
>> And you couldn’t even manage without three different botched releases.
>>
>
> I think you are mixing up apreq and httpd releases here.
> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
> one alpha release, and predates the regression.
>
> I'll keep any advice about an apreq release to myself, good luck and
> please be mindful of the CoC
> https://www.apache.org/foundation/policies/conduct
>
>
>>> Respectfully, the tone of that response was unwarranted. There are
>>> better ways to express your opinion that don't require attacks, and
>>> cynicism.
>>>
>>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

The reason the QA around httpd is so lousy lately is because none of you
actually dogfood the software professionally, because no Fortune 500
employer would be caught dead running httpd over nginx in the cloud.

That historically lackadaisical approach to CI has no business persisting
now that you are on GitHub.

And yet it persists.

It also is why you guinea pig your user base instead of respecting them,
because you aren’t a part of that community any more.

And it shows with each new dud delivered to the apreq user base over the
past decade.

So let’s end this fiasco ASAP.

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 7:08 PM Joe Schaefer  wrote:

> Keep your tone policing off list wise guy. If you have something of
> substance to offer to your colleagues other than defensive posturing, let’s
> have it.
>
> Like all these vacuous bug reports missing from the issue tracker about
> apreq, that you rumor mongers like to scare people with.
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:
>
>>
>>
>> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>>
>>> Nobody gives a flying f what you released from trunk. I personally will
>>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>>> a damned what you do with it.
>>>
>>> I just want the warfare against existing libapreq2 users to cease and
>>> desist.
>>>
>>> If there are known vulnerabilities in the existing codebase, you have a
>>> professional obligation to report them to the security team, who have
>>> assured me they will send them my way for proper handling by a competent
>>> engineer.
>>>
>>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>>> mothball the subproject so we need not deal with each other again over it.
>>>
>>> Thanks
>>>
>>> Joe Schaefer, Ph.D.
>>> 
>>> Orion - The Enterprise Jamstack Wiki
>>> 
>>> 
>>> 954.253.3732 
>>>
>>>
>>>
>>>
>>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>>
 On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
 wrote:

> Twenty years in core, with one bug to fix.
> And you couldn’t even manage without three different botched releases.
>

 I think you are mixing up apreq and httpd releases here.
 AIUI the apreq stuff in the core of httpd-trunk has only ever been in
 one alpha release, and predates the regression.

 I'll keep any advice about an apreq release to myself, good luck and
 please be mindful of the CoC
 https://www.apache.org/foundation/policies/conduct


>> Respectfully, the tone of that response was unwarranted. There are better
>> ways to express your opinion that don't require attacks, and cynicism.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Keep your tone policing off list wise guy. If you have something of
substance to offer to your colleagues other than defensive posturing, let’s
have it.

Like all these vacuous bug reports missing from the issue tracker about
apreq, that you rumor mongers like to scare people with.

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 7:03 PM Frank Gingras  wrote:

>
>
> On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:
>
>> Nobody gives a flying f what you released from trunk. I personally will
>> be dead and buried before you release httpd 3.0.  So like you I don’t give
>> a damned what you do with it.
>>
>> I just want the warfare against existing libapreq2 users to cease and
>> desist.
>>
>> If there are known vulnerabilities in the existing codebase, you have a
>> professional obligation to report them to the security team, who have
>> assured me they will send them my way for proper handling by a competent
>> engineer.
>>
>> None have been forthcoming, so that’s reason to release 2.18 as-is and
>> mothball the subproject so we need not deal with each other again over it.
>>
>> Thanks
>>
>> Joe Schaefer, Ph.D.
>> 
>> Orion - The Enterprise Jamstack Wiki
>> 
>> 
>> 954.253.3732 
>>
>>
>>
>>
>> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>>
>>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer 
>>> wrote:
>>>
 Twenty years in core, with one bug to fix.
 And you couldn’t even manage without three different botched releases.

>>>
>>> I think you are mixing up apreq and httpd releases here.
>>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in
>>> one alpha release, and predates the regression.
>>>
>>> I'll keep any advice about an apreq release to myself, good luck and
>>> please be mindful of the CoC
>>> https://www.apache.org/foundation/policies/conduct
>>>
>>>
> Respectfully, the tone of that response was unwarranted. There are better
> ways to express your opinion that don't require attacks, and cynicism.
>

Re: release apreq 2.18 and mothball the project

[Frank Gingras]

On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer  wrote:

> Nobody gives a flying f what you released from trunk. I personally will be
> dead and buried before you release httpd 3.0.  So like you I don’t give a
> damned what you do with it.
>
> I just want the warfare against existing libapreq2 users to cease and
> desist.
>
> If there are known vulnerabilities in the existing codebase, you have a
> professional obligation to report them to the security team, who have
> assured me they will send them my way for proper handling by a competent
> engineer.
>
> None have been forthcoming, so that’s reason to release 2.18 as-is and
> mothball the subproject so we need not deal with each other again over it.
>
> Thanks
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:
>
>> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer  wrote:
>>
>>> Twenty years in core, with one bug to fix.
>>> And you couldn’t even manage without three different botched releases.
>>>
>>
>> I think you are mixing up apreq and httpd releases here.
>> AIUI the apreq stuff in the core of httpd-trunk has only ever been in one
>> alpha release, and predates the regression.
>>
>> I'll keep any advice about an apreq release to myself, good luck and
>> please be mindful of the CoC
>> https://www.apache.org/foundation/policies/conduct
>>
>>
Respectfully, the tone of that response was unwarranted. There are better
ways to express your opinion that don't require attacks, and cynicism.

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Nobody gives a flying f what you released from trunk. I personally will be
dead and buried before you release httpd 3.0.  So like you I don’t give a
damned what you do with it.

I just want the warfare against existing libapreq2 users to cease and
desist.

If there are known vulnerabilities in the existing codebase, you have a
professional obligation to report them to the security team, who have
assured me they will send them my way for proper handling by a competent
engineer.

None have been forthcoming, so that’s reason to release 2.18 as-is and
mothball the subproject so we need not deal with each other again over it.

Thanks

Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 5:17 PM Eric Covener  wrote:

> On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer  wrote:
>
>> Twenty years in core, with one bug to fix.
>> And you couldn’t even manage without three different botched releases.
>>
>
> I think you are mixing up apreq and httpd releases here.
> AIUI the apreq stuff in the core of httpd-trunk has only ever been in one
> alpha release, and predates the regression.
>
> I'll keep any advice about an apreq release to myself, good luck and
> please be mindful of the CoC
> https://www.apache.org/foundation/policies/conduct
>
>

Re: release apreq 2.18 and mothball the project

[Eric Covener]

On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer  wrote:

> Twenty years in core, with one bug to fix.
> And you couldn’t even manage without three different botched releases.
>

I think you are mixing up apreq and httpd releases here.
AIUI the apreq stuff in the core of httpd-trunk has only ever been in one
alpha release, and predates the regression.

I'll keep any advice about an apreq release to myself, good luck and please
be mindful of the CoC https://www.apache.org/foundation/policies/conduct

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

Let's be honest for once Yann. You came up with this hairbrained patch over
2 years ago right here:

https://svn.apache.org/viewvc?view=revision=1895107

Yet the first time anyone actually ran the unit tests for apreq was during
the 2.17 release process **8 months later**.  And because you are such a
prima donna Yann, Joe Orton (who I always respect) would rather remove the
test that flagged your patch, just so he could get the damned thing out the
door without dealing with you further.

Instead, he had to deal with me.   Tradeoffs are everywhere in life.


On Thu, Feb 15, 2024 at 2:41 PM Joe Schaefer  wrote:

> You mean the 2.17 release, where Joe Orton actually patched the test suite
> out of your coercion?
>
> Great engineering.
>
> http://svn.apache.org/viewvc?view=revision=1903489
>
>
> Joe Schaefer, Ph.D.
> 
> Orion - The Enterprise Jamstack Wiki
> 
> 
> 954.253.3732 
>
>
>
>
> On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:
>
>> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
>> >
>> > I gave you beta males an entire year
>>
>> His Alpha Most Serene Highness is too kind to us..
>>
>> > to find an excuse for completely boning the modperl user community for
>> no good reason,
>>
>> _You_ did that (boning the modperl user community), by spitting your
>> venom on everyone here (and in all the forums) and nothing else.
>> You, as a member of the httpd team, could have fixed it and
>> started/encouraged a new release with the one-liner fix, yet your
>> first/primary point was to insult others for having touched your
>> (alphally broken) code and introduced a (betally edge) regression,
>> which His Alpha Most Serene Highness' test suite didn't caught btw.
>>
>> > So far, the only thing to come of putting apreq inside httpd is that
>> third party quality control teams put some elbow grease into fuzzing its
>> various parsers and found a sore spot that you bland engineers felt put
>> upon to fix.  And so you botched that patch too, largely out of spite for
>> the makework.
>>
>> Actually it did find multiple sore spots, otherwise you can imagine
>> that we plebs would never have dared to touch as much of His Alpha
>> Most Serene Highness' code.
>>
>

Re: release apreq 2.18 and mothball the project

[Joe Schaefer]

You mean the 2.17 release, where Joe Orton actually patched the test suite
out of your coercion?

Great engineering.

http://svn.apache.org/viewvc?view=revision=1903489


Joe Schaefer, Ph.D.

Orion - The Enterprise Jamstack Wiki 

954.253.3732 




On Thu, Feb 15, 2024 at 2:13 PM Yann Ylavic  wrote:

> On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
> >
> > I gave you beta males an entire year
>
> His Alpha Most Serene Highness is too kind to us..
>
> > to find an excuse for completely boning the modperl user community for
> no good reason,
>
> _You_ did that (boning the modperl user community), by spitting your
> venom on everyone here (and in all the forums) and nothing else.
> You, as a member of the httpd team, could have fixed it and
> started/encouraged a new release with the one-liner fix, yet your
> first/primary point was to insult others for having touched your
> (alphally broken) code and introduced a (betally edge) regression,
> which His Alpha Most Serene Highness' test suite didn't caught btw.
>
> > So far, the only thing to come of putting apreq inside httpd is that
> third party quality control teams put some elbow grease into fuzzing its
> various parsers and found a sore spot that you bland engineers felt put
> upon to fix.  And so you botched that patch too, largely out of spite for
> the makework.
>
> Actually it did find multiple sore spots, otherwise you can imagine
> that we plebs would never have dared to touch as much of His Alpha
> Most Serene Highness' code.
>

Re: release apreq 2.18 and mothball the project

[Yann Ylavic]

On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote:
>
> I gave you beta males an entire year

His Alpha Most Serene Highness is too kind to us..

> to find an excuse for completely boning the modperl user community for no 
> good reason,

_You_ did that (boning the modperl user community), by spitting your
venom on everyone here (and in all the forums) and nothing else.
You, as a member of the httpd team, could have fixed it and
started/encouraged a new release with the one-liner fix, yet your
first/primary point was to insult others for having touched your
(alphally broken) code and introduced a (betally edge) regression,
which His Alpha Most Serene Highness' test suite didn't caught btw.

> So far, the only thing to come of putting apreq inside httpd is that third 
> party quality control teams put some elbow grease into fuzzing its various 
> parsers and found a sore spot that you bland engineers felt put upon to fix.  
> And so you botched that patch too, largely out of spite for the makework.

Actually it did find multiple sore spots, otherwise you can imagine
that we plebs would never have dared to touch as much of His Alpha
Most Serene Highness' code.

Re: age in proxy_balancer_method

[jean-frederic clere]

On 12/21/23 19:32, Rainer Jung wrote:
I guess it could be like this: when Mladen originally implemented the by 
requests load balancing method in mod_jk he used the count and subtract 
method for the counters. He then ported this to mod_proxy_balancer and I 
think it is still, how by requests counting woorks there.


There are pros and cons, e.g. in case a worker goes down for some time. 
A bit later we switched in mod_jk to a count and divide, where division 
by 2 was done roughly every 60 seconds (configurable).


I have looked to different solutions: The most easy is to add age=n 
parameter to the balancer definition and divide the transferred, read 
and elected by 2 every n seconds for the workers.


Other logic would be to store those values and reset them if they don't 
change.


The busy don't need any aging ;-)

I will prepare a PR for first review tomorrow.



I think the idea of the age method was roughly, that you could implement 
a balanvcer method, that registers a mod_watchdog task, that regularly 
ages the balancing counters. Aging because you want to give the past a 
smaller influence on the balancing decision than the more recent activity.


I hope that's understandable and maybe Jim remembers something similar 
to that.


Best regards,

Rainer

Am 21.12.23 um 08:23 schrieb jean-frederic clere:

On 12/20/23 21:22, Jim Jagielski wrote:
I'll have to go back through my notes... I do recall adding fields 
that although
were not being used at the time, were _going to be used_ as some 
point, and

I didn't want to have to worry about ABI compatibility.


Cool I will wait before implementing something that breaks your design 
;-)




On Dec 14, 2023, at 8:27 AM, jean-frederic clere  
wrote:


Hi,

Any examples or docs about:
apr_status_t (*age)(proxy_balancer *balancer, server_rec *s);

In struct proxy_balancer_method?

--
Cheers

Jean-Frederic


--
Cheers

Jean-Frederic

Re: reset in proxy_balancer_method

[jean-frederic clere]

On 2/15/24 13:04, Ruediger Pluem wrote:



On 2/15/24 9:28 AM, jean-frederic clere wrote:

On 2/14/24 20:54, Ruediger Pluem wrote:



On 2/14/24 3:45 PM, jean-frederic clere wrote:

On 2/14/24 08:19, Ruediger Pluem wrote:



On 2/9/24 11:59 AM, jean-frederic clere wrote:

Hi,

I have noted to the reset() clean up too much in the balancers:
mod_lbmethod_bybusyness.c for example does:
+++
   for (i = 0; i < balancer->workers->nelts; i++, worker++) {
   (*worker)->s->lbstatus = 0;
   ap_proxy_set_busy_count(*worker, 0); /* BAD */
   }
+++
In fact reset() is called by ap_proxy_initialize_balancer() when a child 
process is created... Resetting the counters messes up
the logic.

Does it make sense to stop calling reset() from ap_proxy_initialize_balancer() 
or is it better to fix all reset()?


I am not sure what the original idea / intention of reset was. Until this is 
clarified I would not remove the call to reset in
ap_proxy_initialize_balancer(). In ap_proxy_sync_balancer the call to it is 
guarded by a check for the need_reset flag. Maybe
this
gives a hint.


Rethinking this. I guess we lack a clear API definition of the reset method of 
a balancer provider and it does not really seem
sensible to reset the stats in case a new child is created. Hence I guess the 
regression risk is rather low when just removing
this call to reset.



The need_reset is set when a worker is enabled or when the load balancing 
method is changed.


Isn't that a similar situation to when a worker is added (in respect to the 
point below)?


The worker are added disabled.


Which means stuff gets reset once they get enabled?


Correct ;-)



Regards

Rüdiger


--
Cheers

Jean-Frederic

Re: reset in proxy_balancer_method

[Ruediger Pluem]

On 2/15/24 9:28 AM, jean-frederic clere wrote:
> On 2/14/24 20:54, Ruediger Pluem wrote:
>>
>>
>> On 2/14/24 3:45 PM, jean-frederic clere wrote:
>>> On 2/14/24 08:19, Ruediger Pluem wrote:


 On 2/9/24 11:59 AM, jean-frederic clere wrote:
> Hi,
>
> I have noted to the reset() clean up too much in the balancers:
> mod_lbmethod_bybusyness.c for example does:
> +++
>   for (i = 0; i < balancer->workers->nelts; i++, worker++) {
>   (*worker)->s->lbstatus = 0;
>   ap_proxy_set_busy_count(*worker, 0); /* BAD */
>   }
> +++
> In fact reset() is called by ap_proxy_initialize_balancer() when a child 
> process is created... Resetting the counters messes up
> the logic.
>
> Does it make sense to stop calling reset() from 
> ap_proxy_initialize_balancer() or is it better to fix all reset()?

 I am not sure what the original idea / intention of reset was. Until this 
 is clarified I would not remove the call to reset in
 ap_proxy_initialize_balancer(). In ap_proxy_sync_balancer the call to it 
 is guarded by a check for the need_reset flag. Maybe
 this
 gives a hint.
>>
>> Rethinking this. I guess we lack a clear API definition of the reset method 
>> of a balancer provider and it does not really seem
>> sensible to reset the stats in case a new child is created. Hence I guess 
>> the regression risk is rather low when just removing
>> this call to reset.
>>
>>>
>>> The need_reset is set when a worker is enabled or when the load balancing 
>>> method is changed.
>>
>> Isn't that a similar situation to when a worker is added (in respect to the 
>> point below)?
> 
> The worker are added disabled.

Which means stuff gets reset once they get enabled?

Regards

Rüdiger

Re: reset in proxy_balancer_method

[jean-frederic clere]

On 2/14/24 20:54, Ruediger Pluem wrote:



On 2/14/24 3:45 PM, jean-frederic clere wrote:

On 2/14/24 08:19, Ruediger Pluem wrote:



On 2/9/24 11:59 AM, jean-frederic clere wrote:

Hi,

I have noted to the reset() clean up too much in the balancers:
mod_lbmethod_bybusyness.c for example does:
+++
  for (i = 0; i < balancer->workers->nelts; i++, worker++) {
  (*worker)->s->lbstatus = 0;
  ap_proxy_set_busy_count(*worker, 0); /* BAD */
  }
+++
In fact reset() is called by ap_proxy_initialize_balancer() when a child 
process is created... Resetting the counters messes up
the logic.

Does it make sense to stop calling reset() from ap_proxy_initialize_balancer() 
or is it better to fix all reset()?


I am not sure what the original idea / intention of reset was. Until this is 
clarified I would not remove the call to reset in
ap_proxy_initialize_balancer(). In ap_proxy_sync_balancer the call to it is 
guarded by a check for the need_reset flag. Maybe this
gives a hint.


Rethinking this. I guess we lack a clear API definition of the reset method of 
a balancer provider and it does not really seem
sensible to reset the stats in case a new child is created. Hence I guess the 
regression risk is rather low when just removing
this call to reset.



The need_reset is set when a worker is enabled or when the load balancing 
method is changed.


Isn't that a similar situation to when a worker is added (in respect to the 
point below)?


The worker are added disabled.










There is another thing adding a new worker via /balancer-manager/ probably 
requires some kind of reset() otherwise all the load
moves to the new worker which is not the best May be calling age() or 
triggering calls to age() can help.


Doesn't ap_proxy_sync_balancer take care of this which is called before 
processing a request?



Regards

Rüdiger


--
Cheers

Jean-Frederic