Re: 2.4.0 GA This week?
0On 1/2/2012 3:06 PM, William A. Rowe Jr. wrote: On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? I all for stop any and all API changes other than anything that may require fixing these. I am all for RCs if it means changing the -dev is to -rc# I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Yes, Mario's mod_proxy_balancer/slotmem shm errors I am also still getting/ Mario, I know you read this list ... chime in your PR# and any other possitivle showstopper that may be on any platform other than building ... not that I count :) Other than these few ... bummers ... guys ... this is one of the best servers I have seen. Cheets Gregg
Re: 2.4.0 GA This week?
Honesty, never tries with these on ... especially sendfile ... slows us wintards outbound down bigtime. On 1/2/2012 3:08 PM, William A. Rowe Jr. wrote: On 1/1/2012 12:30 PM, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers Does disabling the EnableSendfile/EnableMMAP directives alter either of these cases? It really appears that socket reuse is to blame here. We know there are plenty of windows socket stack drivers who barf on disconnecting and recycling sockets through transmitfile.
Re: remove mod_heart* from 2.4?(was: 2.4.0 GA This week?)
Since I have been the most vocal about this watchdog/hearmonitor/heartbeats on windows ... I should chime in. I can tell someone what each do (as far as I have seen). There are, minimal docvs on all but watchdog (which is required for a couple) ... but ... look at my emails in the past ... am hardly the one to write docs :) G On 1/2/2012 10:12 PM, Sander Temme wrote: On Jan 2, 2012, at 8:09 PM, Eric Covener wrote: I will crank out docs for these tomorrow and ping paul to review. Thank you for getting this going: it seems to be the most constructive way to resolve this issue. S.
Re: 2.4.0 GA This week?
My vote ... Stefan, wherever it fits (depends on whom I speak to) , these are showstoppers. But, it can be said these are one OS specific ... which usually does not stop the press AFAIK. I can say however .. as a small time distributor ... this will be noted as the problems yet remaining on this one platform (windows) ... and if these few problems do not affect any of my distributees ... then they should move on to 2.4. Regards, Gregg On 1/2/2012 10:50 PM, Stefan Fritsch wrote: On Tuesday 03 January 2012, William A. Rowe Jr. wrote: On 1/2/2012 4:10 PM, Stefan Fritsch wrote: On Sunday 01 January 2012, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers - Rewrite P On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? No. The status of 2.4.0 will be determined by vote. I was just pointing out how I intend to vote in the face of the Windows issues and am lobbying for other people to consider this as a valid option, too.
Re: 2.4.0 GA This week?
Suprised. When ASF is going that way, we theoritical can have: GA Windows 2.4 Beta OSX 2.3.19 Alpha Ubuntu 2.3.19 Steffen On Monday 02/01/2012 at 23:11, Stefan Fritsch wrote: On Sunday 01 January 2012, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers - Rewrite P On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely.
Re: 2.4.0 GA This week?
Suprised. When ASF is going that way, we theoritical can have: GA Windows 2.4 Beta OSX 2.3.19 Alpha Ubuntu 2.3.19 Steffen On Monday 02/01/2012 at 23:11, Stefan Fritsch wrote: On Sunday 01 January 2012, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers - Rewrite P On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely.
Re: 2.4.0 GA This week?
I agree with Gregg, this server is the best I ever worked with. Since one of the early betas I run it on my prod systems on windows and *nix. Except for known issues it works like a charm. A public beta or RC does not hurt. More testers may find some more stuff to fix. An api freeze coulod gve the 3rd party module guys give the time to fix and or build their modules against coming 2.4 Go the way on releasing it for one system as GA and others as beta is confusing in my eyes. Just my 2 cents Mario I all for stop any and all API changes other than anything that may require fixing these. I am all for RCs if it means changing the -dev is to -rc# I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Yes, Mario's mod_proxy_balancer/slotmem shm errors I am also still getting/ Mario, I know you read this list ... chime in your PR# and any other possitivle showstopper that may be on any platform other than building ... not that I count :) Other than these few ... bummers ... guys ... this is one of the best servers I have seen. Cheets Gregg
Re: 2.4.0 GA This week?
On Tuesday 03/01/2012 at 09:16, Gregg L. Smith wrote: 0On 1/2/2012 3:06 PM, William A. Rowe Jr. wrote: On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? I all for stop any and all API changes other than anything that may require fixing these. I am all for RCs if it means changing the -dev is to -rc# I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Yes, Mario's mod_proxy_balancer/slotmem shm errors I am also still getting/ Mario, I know you read this list ... chime in your PR# and any other possitivle showstopper that may be on any platform other than building ... not that I count :) Other than these few ... bummers ... guys ... this is one of the best servers I have seen. Cheets Gregg Second on that, is running great HTTP only. Gregg, you made a typo ...realized SSL with AcceptFilter httpd none was..., must be https.
Re: 2.4.0 GA This week?
On Tuesday 03/01/2012 at 09:16, Gregg L. Smith wrote: 0On 1/2/2012 3:06 PM, William A. Rowe Jr. wrote: On Sunday 01/01/2012 at 19:03, Mario Brandt wrote: The loadbalancer still crashes on windows. See https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 We should try to get at least the rewrite/proxy issue resolved, first. About the Windows-onlly issues... Well, if there are not sufficient developers who have time and inclination to look into those, I would rather release 2.4.0 as GA on unix, beta on Windows, than delay it indefinitely. When we tag and roll 2.4.0, if it isn't up to snuff, it won't pass the vote for GA, but perhaps it will pass the vote for beta (or alpha). I'm not sure where the impetus came from to change the way the HTTP Project operates at this particular point in time. It certainly hasn't been discussed much on this list, or put up for a vote. The methodology for handling releases was all hashed out a number of years ago and was assembled from consensus. Has that consensus changed? I all for stop any and all API changes other than anything that may require fixing these. I am all for RCs if it means changing the -dev is to -rc# I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Yes, Mario's mod_proxy_balancer/slotmem shm errors I am also still getting/ Mario, I know you read this list ... chime in your PR# and any other possitivle showstopper that may be on any platform other than building ... not that I count :) Other than these few ... bummers ... guys ... this is one of the best servers I have seen. Cheets Gregg Second on that, is running great HTTP only. Gregg, you made a typo ...realized SSL with AcceptFilter httpd none was..., must be https.
Re: 2.4.0 GA This week?
Was off. Still, I want to ask to reconsider going back to the 2.2 behavior (for the time being). On Tuesday 03/01/2012 at 00:09, William A. Rowe Jr. wrote: On 1/1/2012 12:30 PM, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers Does disabling the EnableSendfile/EnableMMAP directives alter either of these cases? It really appears that socket reuse is to blame here. We know there are plenty of windows socket stack drivers who barf on disconnecting and recycling sockets through transmitfile.
Re: 2.4.0 GA This week?
Was off. Still, I want to ask to reconsider going back to the 2.2 behavior (for the time being). On Tuesday 03/01/2012 at 00:09, William A. Rowe Jr. wrote: On 1/1/2012 12:30 PM, Steffen wrote: Also IMHO blocking GA: - SSL on windows not usable - Hanging logging workers Does disabling the EnableSendfile/EnableMMAP directives alter either of these cases? It really appears that socket reuse is to blame here. We know there are plenty of windows socket stack drivers who barf on disconnecting and recycling sockets through transmitfile.
Re: httpd-2.3.16-beta make install fails...
On Tue, Dec 27, 2011 at 8:56 AM, Michael Felt mamf...@gmail.com wrote: AIX 5.3.7 xlC v7 After minor edits, compiles (with warnings) root@x105:[/data/prj/httpd-2.3.16-beta]./httpd -V Server version: Apache/2.3.16 (Unix) Server built: Dec 27 2011 07:28:45 Server's Module Magic Number: 20111203:0 Server loaded: APR 1.4.5, APR-UTIL 1.4.1 Compiled using: APR 1.4.5, APR-UTIL 1.4.1 Architecture: 32-bit Server MPM: worker threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT=/opt/apache2 -D SUEXEC_BIN=/opt/apache2/bin/suexec -D DEFAULT_PIDLOG=/var/apache2/run/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=/etc/apache2/mime.types -D SERVER_CONFIG_FILE=/etc/apache2/httpd.conf make install fails... ... Target local-install is up to date. Target install is up to date. Making install in modules Making install in aaa rm -f /var/apache2/libexec/mod_authn_file.so /data/prj/httpd-2.3.16-beta/srclib/apr/libtool --silent --mode=install install mod_authn_file.la /var/apache2/libexec/ find: bad status-- /var/apache2/libexec/mod_authn_file.so install: File mod_authn_file.so was not found. make: 1254-004 The error code from the last command is 2. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. FWIW we discovered offline that we needed GNU coreutils (for /opt/freeware/bin/install) on AIX.
Re: 2.4.0 GA This week?
One reason to announce my intent was to basically encourage people to try HEAD and see how it works for them. If we lack sufficient people with access and/or knowledge about Windows, or if they don't bother to try things out until they get a tagged and rolled tarball (or whatever), then that is the issue that needs to be discussed and resolved. Another reason was to also encourage people to practice some restraint against willy-nilly changes, so that the delta between the last beta and what we hope to go GA with isn't so large as to warrant YAB (Yet Another Beta)... Of course, bugs should be squashed, but YAR (Yet Another Refactor) should be carefully considered.
Re: 2.4.0 GA This week?
On 1/3/2012 3:30 AM, Steffen wrote: Still, I want to ask to reconsider going back to the 2.2 behavior (for the time being). Highly unlikely for the reasons I responded nearly a year or so back. This bug is irritating, but it is exactly that, a bug. Not 1000's of lines of redundant code. Spent last week investigating this and several other obstacles, but I don't have an affirmative response yet. Gregg's recent post will likely help me a bunch. Stefan, you could likely help on the logging puzzle. If you look at http://httpd.apache.org/dev/debugging.html#backtrace-win you have some basic steps to trigger a core for a -running- httpd.exe. If you could do this once a collection of 'L' statuses have accumulated for the child process, the backtraces of those threads would be very helpful. I would anticipate this bug is relatively new, in core, and not the win32 mpm, but could be surprised.
Re: 2.4.0 GA This week?
On 1/3/2012 2:15 AM, Gregg L. Smith wrote: I all for stop any and all API changes other than anything that may require fixing these. Hopefully, there is consensus that the API is baked :) I am all for RCs if it means changing the -dev is to -rc# -rc# isn't an httpd concept. Long threads explain the position of the group on -rc#'s vs .0, .1, .2 etc. Other than Jim's post proposing rc's I didn't see any interest in this, and it certainly violates the principals that 1) version numbers are cheap, and 2) don't recycle burnt revisions. That was actually my only point, that it is likely time for 2.4.0, but rc's don't fit here without some group consensus that we use rc's. AFAIK we resoundingly rejected that model. I'm sorry I signed off before I realized SSL with AcceptFilter httpd none was still a problem on Windoze. Nothing to apologize for, thank you for reporting once you had discovered them. It would have been lovely if someone had caught this during my last refactoring when we fixed the 80/20... but... c'est la vie.
Re: 2.4.0 GA This week?
On 1/3/2012 7:48 AM, Jim Jagielski wrote: One reason to announce my intent was to basically encourage people to try HEAD and see how it works for them. If we lack sufficient people with access and/or knowledge about Windows, or if they don't bother to try things out until they get a tagged and rolled tarball (or whatever), then that is the issue that needs to be discussed and resolved. +1 (or branches/2.4.x/ rather ;-) Another reason was to also encourage people to practice some restraint against willy-nilly changes, so that the delta between the last beta and what we hope to go GA with isn't so large as to warrant YAB (Yet Another Beta)... Of course, bugs should be squashed, but YAR (Yet Another Refactor) should be carefully considered. +1
Re: 2.4.0 GA This week?
On Jan 3, 2012, at 10:01 AM, William A. Rowe Jr. wrote: On 1/3/2012 7:48 AM, Jim Jagielski wrote: One reason to announce my intent was to basically encourage people to try HEAD and see how it works for them. If we lack sufficient people with access and/or knowledge about Windows, or if they don't bother to try things out until they get a tagged and rolled tarball (or whatever), then that is the issue that needs to be discussed and resolved. +1 (or branches/2.4.x/ rather ;-) Yeppers Thats why I said HEAD instead of trunk... HEAD of the 2.4 branch...
Change to Module DB
User ID : 1758 Title: Apache Rivet Details : https://modules.apache.org/search.php?id=2592
Backtrace on Windows Docu outdated
http://httpd.apache.org/dev/debugging.html#backtrace-win There is no Dr Watson anymore in Windows Server 2008. Steffen
Backtrace on Windows Docu outdated
http://httpd.apache.org/dev/debugging.html#backtrace-win There is no Dr Watson anymore in Windows Server 2008. Steffen
Re: Backtrace on Windows Docu outdated
You can still modify Windows' default error reporting to save a backtrace: http://msdn.microsoft.com/en-us/library/bb787181%28VS.85%29.aspx Mathijs On Tue, Jan 3, 2012 at 7:48 PM, Steffen i...@apachelounge.com wrote: http://httpd.apache.org/dev/**debugging.html#backtrace-winhttp://httpd.apache.org/dev/debugging.html#backtrace-win There is no Dr Watson anymore in Windows Server 2008. Steffen
Re: Backtrace on Windows Docu outdated
On 1/3/2012 12:48 PM, Steffen wrote: http://httpd.apache.org/dev/debugging.html#backtrace-win There is no Dr Watson anymore in Windows Server 2008. Of course you can accomplish the same with windbg, but instructions on precisely how to do it would be much more wordy to the point of not fitting into the scope of our simple background docs (e.g. we don't try to cover all of gdb, dbx, etc etc). http://blogs.technet.com/b/askperf/archive/2007/06/15/capturing-application-crash-dumps.aspx see the comments on ADplus (debugging tools for windows is probably the simplest, install the flavor for x86 or x64 to correspond to the version of httpd you would be experimenting with)
Re: 2.4.0 GA This week?
On Tuesday 03 January 2012, William A. Rowe Jr. wrote: On 1/3/2012 3:30 AM, Steffen wrote: Still, I want to ask to reconsider going back to the 2.2 behavior (for the time being). Highly unlikely for the reasons I responded nearly a year or so back. This bug is irritating, but it is exactly that, a bug. Not 1000's of lines of redundant code. Spent last week investigating this and several other obstacles, but I don't have an affirmative response yet. Gregg's recent post will likely help me a bunch. I am glad that there has been some activity on this in the background, thanks. Stefan, you could likely help on the logging puzzle. If you look s/Stefan/Steffen/ at http://httpd.apache.org/dev/debugging.html#backtrace-win you have some basic steps to trigger a core for a -running- httpd.exe. If you could do this once a collection of 'L' statuses have accumulated for the child process, the backtraces of those threads would be very helpful. I would anticipate this bug is relatively new, in core, and not the win32 mpm, but could be surprised. One thing that comes to mind was the changing of the EOR bucket cleanup to a pre-cleanup. But that was already 1 year ago. I have no idea how this could lead to a hang, do you think it could have broken some assumption in the win32 mpm?
Re: Win 2.3.16 :: SSL and AcceptFilter
On 30.12.2011 22:04, Gregg L. Smith wrote: On 12/27/2011 10:40 AM, Steffen wrote: Gregg reported it also: I've also found AcceptFilter https none to be problematic. First time you hit a site via https it usually comes up with a blank white nothing. Hitting reload and it comes up proper. That I did, fishing to see if others were seeing the same thing. It looks like they are. I finally also managed to build 2.4.x on Windows 7 using Visual Studio 10. Un(?)fortunately I couldn't reproduce this problem. But the system I use also works with default AcceptFilter. For the reference: - Windows 7 64 bits Professional - Visual Studio 10 / Windows SDK 7.1 - OpenSSL 1.0.0e, libz 1.2.5, pcre 8.12 - httpd 2.4.x r1226941 - apr 1.4.5, apu 1.4.1, api 1.2.1 Everything build as win7 / x86 / Release. I tried to reproduce with various AcceptFilter setting inclusing https none using MSIE, FF and Chrome. I always get the response on the first request. Steffen, Gregg et. al.: Can you reproduce on a test system? Did you already reproduce once with increased log level, e.g. LogLevel info ssl_module:trace8 mpm_winnt_module:trace8 or maybe, since it seems you can reproduce with a single request just use LogLevel trace8 and post one example for the working case and one for the broken case. Regards, Rainer -Original Message- From: Steffen Sent: Tuesday, December 27, 2011 7:21 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.16 :: SSL and AcceptFilter Hard to catch, but I was lucky. These are the steps with loglevel info: Start httpd.exe with AcceptFilter https none 1) In browser https://devxp 2) response browser not found in access log: nothing in error log: [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2136] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH02008: SSL library error 1 in handshake (server devxp:443) [ssl:info] [pid 2432:tid 1036] SSL Library Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol -- speaking not SSL to HTTPS port!? [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2137] AH01998: Connection closed to child 63 with abortive shutdown (server devxp:443) 3) In browser press refresh 4)Response is fine in accesslog: SSLv3 RC4-SHA GET / HTTP/1.1 200 46 - Mozilla/4.0 (compatible; MSIE 6.0;... in error log: [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2138] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] (70014)End of file found: [client 192.168.1.13:2138] AH01991: SSL input filter read failed. [ssl:info] [pid 2432:tid 1036] [client 192.168.1.13:2139] AH01964: Connection to child 63 established (server devxp:443) [ssl:info] [pid 2432:tid 1036] (OS 10060)A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. : [client 192.168.1.13:2139] AH01991: SSL input filter read failed. -Original Message- From: William A. Rowe Jr. Sent: Tuesday, December 27, 2011 5:42 PM To: dev@httpd.apache.org Subject: Re: Win 2.3.16 :: SSL and AcceptFilter On 12/27/2011 9:46 AM, Steffen wrote: Reported here already the issue. Also in the AL forum is one with the same issue. Still there definitly is an issue with Acceptfilter and SSL. When AcceptFilter https none: Sometimes page is not displayed, eg. in Chrome with errors Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error. or Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error. Nothing in the logs. --- almost always means you want to change LogLevel to debug --- (or maybe even info level will be sufficient). With the new methodology, you can toggle the mpm alone to debug level. Something like; LogLevel info ssl_module:debug mpm_winnt_module:debug
Re: Win 2.3.16 :: SSL and AcceptFilter
On 1/3/2012 9:19 PM, Rainer Jung wrote: On 30.12.2011 22:04, Gregg L. Smith wrote: On 12/27/2011 10:40 AM, Steffen wrote: Gregg reported it also: I've also found AcceptFilter https none to be problematic. First time you hit a site via https it usually comes up with a blank white nothing. Hitting reload and it comes up proper. That I did, fishing to see if others were seeing the same thing. It looks like they are. I finally also managed to build 2.4.x on Windows 7 using Visual Studio 10. Un(?)fortunately I couldn't reproduce this problem. But the system I use also works with default AcceptFilter. Reports state you need to combine this with EnableSendfile Off (and perhaps EnableMMAP Off) which would disable TransmitFile/socket disconnect/recycling.
