Time for 2.4.24!
We have a few items in STATUS that, imo, should be tested, voted-on and the committed to the httpd-2.4 branch in anticipation of a new release SOON! I'd like to have a T&R the end of next week, if possible so we can start off December (or be close to "starting it off") with a new release for the community. I'll RM.
Re: Time for 2.4.24!
hello? hello? Anyone there? :) > On Nov 21, 2016, at 7:47 AM, Jim Jagielski wrote: > > We have a few items in STATUS that, imo, should be tested, voted-on > and the committed to the httpd-2.4 branch in anticipation of a new > release SOON! I'd like to have a T&R the end of next week, if > possible so we can start off December (or be close to "starting > it off") with a new release for the community. > > I'll RM.
Re: Time for 2.4.24!
Don't look at me! Have my hands full with h2 stuff... ;-) > Am 01.12.2016 um 15:28 schrieb Jim Jagielski : > > hello? hello? Anyone there? :) > >> On Nov 21, 2016, at 7:47 AM, Jim Jagielski wrote: >> >> We have a few items in STATUS that, imo, should be tested, voted-on >> and the committed to the httpd-2.4 branch in anticipation of a new >> release SOON! I'd like to have a T&R the end of next week, if >> possible so we can start off December (or be close to "starting >> it off") with a new release for the community. >> >> I'll RM. >
Re: Time for 2.4.24!
Trying to look at the event stuff and the strict stuff. If any more experienced event folks are lurking, help on the review would be great (And thanks to sf!) On Thu, Dec 1, 2016 at 9:28 AM, Jim Jagielski wrote: > hello? hello? Anyone there? :) > >> On Nov 21, 2016, at 7:47 AM, Jim Jagielski wrote: >> >> We have a few items in STATUS that, imo, should be tested, voted-on >> and the committed to the httpd-2.4 branch in anticipation of a new >> release SOON! I'd like to have a T&R the end of next week, if >> possible so we can start off December (or be close to "starting >> it off") with a new release for the community. >> >> I'll RM. > -- Eric Covener cove...@gmail.com
Re: Time for 2.4.24!
On Thu, Dec 1, 2016 at 9:06 AM, Eric Covener wrote: > Trying to look at the event stuff and the strict stuff. > > If any more experienced event folks are lurking, help on the review > would be great (And thanks to sf!) > I found the PR itself to be full of useful data for review (including some reporters' test results against the proposed patches).
Re: Time for 2.4.24!
On Thu, Dec 1, 2016 at 8:28 AM, Jim Jagielski wrote: > hello? hello? Anyone there? :) > > > On Nov 21, 2016, at 7:47 AM, Jim Jagielski wrote: > > > > We have a few items in STATUS that, imo, should be tested, voted-on > > and the committed to the httpd-2.4 branch in anticipation of a new > > release SOON! > +1. There is a proposed mitigation of the many security defects intrinsic in HTTP server implementations sitting in STATUS with one vote, I'd think the project would want to correct this and any undisclosed vulnerabilities in the queue prior to T&R. Sooner, the better. Cheers, Bill
Re: Time for 2.4.24!
On Thu, Dec 1, 2016 at 10:06 AM Eric Covener wrote: > Trying to look at the event stuff and the strict stuff. > > If any more experienced event folks are lurking, help on the review > would be great (And thanks to sf!) > This lurker isn't up to doing a full on line-by-line review. But I will take the bait and make some observations: * I am a huge sf fan. Wish he had been around in the 2.0 beta and early event development days. * What I see here http://apache.org/server-status and here https://bz.apache.org/bugzilla/show_bug.cgi?id=53555 reinforces the above. * The scoreboard "squatting" code was one of the ugliest warts I ever had the displeasure to try to band-aid. Good riddance. * Test cases rock! Hopefully we've got some that can run big workloads with both normal and very long running requests, plus MPM tuning parameters to intentionally make it thrash processes. How did squatting come about? The 2.0 threaded MPM simply took 1.3's one dimensional array data structure for the scoreboard and turned it into a two dimensional flat array. Ops! Design discussions of doing a more sophisticated scoreboard data structure were squashed by someone with a proprietary module which walked the scoreboard. The threaded MPM also in inherited 1.3's management of numbers of workers, and just translated it from worker processes into worker threads. Then we started hitting "scoreboard full" errors with mixtures of fast and slw requests, a la PR 53555, and squatting was born. The threaded MPM became the worker MPM which evolved into event, and you know the rest. * What about worker? It's got a scoreboard full / squatting problem too. I'd say either patch it too,or just phase it out. Maybe y'all have already decided on the latter. If not, it is trivial to make event behave like worker, controlled by a config directive if you feel that's necessary. I believe the code is in ap_process_async_connection. I *really* regret not doing that in the first event patch I posted to this list. Que sera, sera. Enough ranting. Greg Ames