+1 to removing support of mom prefork. I'd prefer it still start and if configured, with an [error] level alert in the logs and simply be disabled. Server must start when module is loaded but not configured, e.g. in test framework, IMO.
On Jul 6, 2017 10:31 AM, "Stefan Eissing" <stefan.eiss...@greenbytes.de> wrote: > Correction: websockets are not defined over h2. To make a more "real life" > scenario: > > One example is a long polling request by a javascript component. During > the long poll, the browser will not get other responses. > > More esoteric: when content filters (brotli, gzip) are in place, > compression happens in the h2 worker thread. If one PUSHes such a resource, > clients sometimes use h2 flow control to delay the sending of a response. > This would deadlock the connection in a prefork model. > > These are complications not easily debugged or reproducible. > > > Am 06.07.2017 um 17:15 schrieb Stefan Eissing < > stefan.eiss...@greenbytes.de>: > > > > Hej, > > > > I tried to gather some discussion about this. Should have polled this > mailing list. You can read most of it here: https://github.com/icing/mod_ > h2/issues/142 > > > > tl;dr > > > > I had several reports in the past of people being disappointed about h2 > performance, only to learn they were on prefork. Which means every request > is processed serially (with static files being an exception, as long as no > filters prevent this). > > > > In 2.4.26 I changed the (undocumented) default from 1 to 4 h2 workers, > which brought us to the issue I linked. The easy fix is 'H2MaxWorkers 1' in > the config and you have the pre-2.4.26 behaviour. > > > > Regardless of the discussion if the change in 2.4.26 was reasonable or > not: it is not possible to map the prefork single-thread requirement on to > HTTP/2. Not going to work. One long running request, one websocket opened, > and your browser will stall. > > > > This is not a bug, it is the collision of the processing models. > > > > So, I think disabling it prevent user from shooting themselves in the > foot. If you are on prefork, you'd want the 6 parallel HTTP/1.1 > connections, not h2. > > > > Does this make sense? > > > > Cheers, > > > > Stefan > > > > PS. Yes, I know that one /could/ make parallel processes work in prefork > by placing the h2 dispatching in a parent process. If someone wants to > implement that, be my guest. > > > > > >> Am 06.07.2017 um 16:55 schrieb Bert Huijben <b...@qqmail.nl>: > >> > >> > >> > >>> -----Original Message----- > >>> From: Jim Jagielski [mailto:j...@jagunet.com] > >>> Sent: woensdag 5 juli 2017 18:49 > >>> To: dev@httpd.apache.org > >>> Subject: Re: 2.4.27 > >>> > >>> These are just the fixes/regressions noted in CHANGES: > >>> > >>> Changes with Apache 2.4.27 > >>> > >>> *) mod_lua: Improve compatibility with Lua 5.1, 5.2 and 5.3. > >>> PR58188, PR60831, PR61245. [Rainer Jung] > >>> > >>> *) mod_http2: disable and give warning when mpm_prefork is > >>> encountered. The server will > >>> continue to work, but HTTP/2 will no longer be negotiated. [Stefan > >> Eissing] > >> > >> Can somebody point me to the reasoning behind this? > >> > >> I have this configuration on FreeBSD with older Httpd versions, and it > works > >> just fine for my limited load. > >> > >> Switching to a different model will require compiling more ports myself > as > >> the FreeBSD packaging system is optimized for this model. > >> > >> > >> I do understand that there is a better mapping of http/2 streams with > the > >> more modern MPMs, but there must be a reason that it worked and no > longer > >> can be supported in the future. I assume this reason is already > documented > >> somewhere... > >> > >> Thanks, > >> > >> Bert > >> > >> > > > >
