From thomasstokes@example.com Fri Jun 01 11:57:04 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 22697 invoked by uid 500); 1 Jun 2001 11:56:59 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 22673 invoked from network); 1 Jun 2001 11:56:57 -0000 Sender: minfrin Message-ID: <thomasstokes@example.com> Date: Fri, 01 Jun 2001 13:05:48 +0200 From: Graham Leggett <thomasstokes@example.com> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.4 ppc) X-Accept-Language: en MIME-Version: 1.0 To: thomasstokes@example.com CC: thomasstokes@example.com Subject: Re: cvs commit: httpd-2.0/modules/metadata mod_headers.c References: <thomasstokes@example.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD6E52BFF659F12AB35E90955" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This is a cryptographically signed message in MIME format. --------------msD6E52BFF659F12AB35E90955 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit thomasstokes@example.com wrote: > Add the 'echo' option to mod_headers Header directive. Use the new option > like this: > > Header echo regex > > If a header received on a request matches regex, it is copied to the response > headers. Would it not make more sense to add "echo" to RequestHeader instead of Header, because it's the request header being echoed...? Regards, Graham -- ----------------------------------------- thomasstokes@example.com "There's a moon over Bourbon Street tonight..." --------------msD6E52BFF659F12AB35E90955 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1MTEwMDE3NDZa MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UEAxMOR3JhaGFt IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5nR87bYWyLVCt XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsElnxYbRRA2SZc CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTArMBsGA1UdEQQU MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCO l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOVAk3LL1KTupvc HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4IMZbuH/rm0ZWp WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdEx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4 MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7Sbngn Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmF zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ 7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwx LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9Dps NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaW GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDYwMTExMDU0OVowIwYJKoZIhvcN AQkEMRYEFHEC/4aj9xFq5yhOl2Gp8YyZrGHMMCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBblEo/NQ+Ly/C5j1GbQd7Q2IeF+oDv prxWAFko1XrMv46Z4EVdvNfrmRo93ueWFCq1mQ9zdYj/jUSOrCyVKXXMCEfs5ArotuSceAQI iCMT+OJtaASWFgjZJMeqjsBO1s0IPFEF0s8M62DinAmGHDECjiMByW7ZJ4smNSpApr8RKA== --------------msD6E52BFF659F12AB35E90955-- From thomasstokes@example.com Fri Jun 01 12:31:47 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 51757 invoked by uid 500); 1 Jun 2001 12:31:40 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 51737 invoked from network); 1 Jun 2001 12:31:39 -0000 Message-ID: <003501c0ea97$c2834d00$71431b09@sashimi> From: "Bill Stoddard" <thomasstokes@example.com> To: <thomasstokes@example.com> References: <thomasstokes@example.com> <thomasstokes@example.com> Subject: Re: cvs commit: httpd-2.0/modules/metadata mod_headers.c Date: Fri, 1 Jun 2001 08:38:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > thomasstokes@example.com wrote: > > > Add the 'echo' option to mod_headers Header directive. Use the new option > > like this: > > > > Header echo regex > > > > If a header received on a request matches regex, it is copied to the response > > headers. > > Would it not make more sense to add "echo" to RequestHeader instead of > Header, because it's the request header being echoed...? > I considered this. It seems technically cleaner (and less error prone) to do all the response header work, including echoing, in the same place during request processing. Splitting the response header work across multiple phases is a good way to introduce non-intuitive behaviour in the header processing (think module order dependencies). That was my thinking anyway. Just to let you know where I am going... I plan to refine the patch I posted to the list a week or so ago that allows mod_log_config style format strings to be passed on Header add|append directives. E.g. Header add YaddaYadda "%t %D" I was also considering adding some conditional processing to the Header add (and append, et. al). Something perhaps like this: Header add YaddaYadda "%t %D" env=var env would be controlled by a SetEnvIf statement to detect, say, the presense of a particular request header. If a particular request header is present, then header YaddaYadda would be added to the response. This will be -really- useful for clients instrumented to do end-to-end performance monitoring. The client can send a special header (signaling its presense) which will cause Apache to collect various bits of information (configurable on the Header add format string) and send that info back to the client in the response headers. Bill From thomasstokes@example.com Fri Jun 01 14:31:03 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 14086 invoked by uid 500); 1 Jun 2001 14:31:02 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 14055 invoked from network); 1 Jun 2001 14:31:00 -0000 Date: Fri, 1 Jun 2001 10:34:18 -0400 From: Rodent of Unusual Size <thomasstokes@example.com> To: ApacheCon Announcements <thomasstokes@example.com>, Apache Announcements <thomasstokes@example.com>, Apache Developers <thomasstokes@example.com> Subject: CFP DEADLINE for ApacheCon 2001 Europe is SATURDAY! Message-ID: <thomasstokes@example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N -----BEGIN PGP SIGNED MESSAGE----- <URGENT> Greetings! To-day is Friday, 1 June 2001, and to-morrow is the DEADLINE for proposing sessions for the ApacheCon 2001 Europe conference in Dublin in October 2001. That means you have less than TWO DAYS to finish procrastinating and submit that session you have been thinking about! :-D The call for participation system will close at 17:30 EDT on Saturday, 2 June 2001. Schedule planning will begin almost immediately, so there is NO chance of submitting late! :-) Speakers for scheduled sessions have their travel and lodging paid by the conference, as well as receiving a speaking fee. Only the session abstract is needed by to-morrow. Required information for presentations are the abstract, a copy of any slides/viewgraphs used ('session notes'), and a copy of a 'white paper' written version of the material (the 'session handout'). The handout should enable someone who does *not* attend the session to get almost as much information as he would have if he *had* attended. To submit a session proposal, log on to the ApacheCon site at http://ApacheCon.Com/html/login.html If you do not already have an account, create one. Once you have logged in, choose the 'submit a CFP' link under the ApacheCon 2001 Europe heading. PLEASE be sure that your email address and biographical information are correct! Thanks! See you in Dublin! </URGENT> - -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/ "All right everyone! Step away from the glowing hamburger!" -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBOxenzJrNPMCpn3XdAQFE2AQAoA76OQnTGH8njngGQKnCAihCVCE8fqCv HpZ7Qq+6ORD4yXUiUxxaP6CAExjJPcu6hBz0SjsnMdN3TOhioLakThRFyANAqfN5 SmnZjRECTCOXBmXucr9MVMFA2MX07a5byPmZqr9jQN1RSikyMJbv+ThfdLtFhKdn qZqqXFXMaSA= =4tKP -----END PGP SIGNATURE----- From thomasstokes@example.com Fri Jun 01 17:06:43 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 25461 invoked by uid 500); 1 Jun 2001 17:06:33 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 25345 invoked from network); 1 Jun 2001 17:06:31 -0000 Message-ID: <thomasstokes@example.com> From: "Brian Moon" <thomasstokes@example.com> To: "William A. Rowe, Jr." <thomasstokes@example.com>, <thomasstokes@example.com> Subject: Binary version of Apache for Win32 Date: Fri, 1 Jun 2001 12:06:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi, Is there anyway other than compiling it myself that I can get a non MSI version of the Apache for Win32. I can't reinstall because i can't uninstall because when I try and uninstall it complains that there is another version installed. Brian Moon ------------------------------------------ dealnews.com, Inc. Makers of dealnews & dealmac http://dealnews.com/ | http://dealmac.com/ From thomasstokes@example.com Fri Jun 01 17:12:24 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 31919 invoked by uid 500); 1 Jun 2001 17:12:22 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 31871 invoked from network); 1 Jun 2001 17:12:18 -0000 Date: Fri, 1 Jun 2001 13:09:03 -0400 Message-Id: <thomasstokes@example.com> X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f From: Jeff Trawick <thomasstokes@example.com> To: thomasstokes@example.com Subject: file/mmap buckets, subrequests, pools, 2.0.18 Reply-to: thomasstokes@example.com X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Greg Ames put together a 2.0.18 build for the purposes of running on apache.org but we were never able to switch over to it from 2.0.16 because of a hard failure with certain types of requests. The problem, trying to simplify a bit: In a subrequest, default_handler opens a file using the pool associated with the subrequest and creates a file bucket. After the subrequest is over, we still have the file bucket with the apr_file_t that had the now-destroyed pool. Any references to the apr_file_t are broken because the pool was destroyed. We finally died back in the main request processing because we referenced an mmap bucket whose apr_mmap_t used the same pool as the apr_file_t. The apr_mmap_t had been overlaid because the storage was released at the end of the main request and subsequently reused for some other purpose. We have never hit this problem with 2.0.16 and we always hit this problem with 2.0.18, leading me to believe that the problem was affected by recent code changes, even though it seems to be a basic design issue. Any ideas about what recent changes might have introduced or exposed this problem? -- Jeff Trawick | thomasstokes@example.com | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From thomasstokes@example.com Fri Jun 01 17:33:05 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 65337 invoked by uid 500); 1 Jun 2001 17:33:03 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 65323 invoked from network); 1 Jun 2001 17:33:02 -0000 X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Fri, 1 Jun 2001 13:33:02 -0400 (EDT) From: Cliff Woolley <thomasstokes@example.com> X-X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com>, <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 1 Jun 2001, Jeff Trawick wrote: > We finally died back in the main request processing because we > referenced an mmap bucket whose apr_mmap_t used the same pool as the > apr_file_t. The apr_mmap_t had been overlaid because the storage was > released at the end of the main request and subsequently reused for > some other purpose. > ... > Any ideas about what recent changes might have introduced or exposed > this problem? Hmmm... ugly. It seems like a pretty basic design issue to me. No changes were made between 2.0.16 and 2.0.18 to the buckets code itself that would have affected this (there were only three substantive commits to the buckets code in that time... two by me and one by Jeff... all unrelated). If anything really did change in that time that broke this, it's in Apache. --Cliff -------------------------------------------------------------- Cliff Woolley thomasstokes@example.com Charlottesville, VA From thomasstokes@example.com Fri Jun 01 17:45:03 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 83752 invoked by uid 500); 1 Jun 2001 17:45:02 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 83740 invoked from network); 1 Jun 2001 17:45:01 -0000 Errors-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> Reply-To: "William A. Rowe, Jr." <thomasstokes@example.com> From: "William A. Rowe, Jr." <thomasstokes@example.com> To: <thomasstokes@example.com> References: <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 Date: Fri, 1 Jun 2001 12:42:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Is this specific to a platform? Perhaps sendfile had been disabled in 2.0.16, and was enabled by all the buildconf cleanup? ----- Original Message ----- From: "Cliff Woolley" <thomasstokes@example.com> To: <thomasstokes@example.com>; <thomasstokes@example.com> Sent: Friday, June 01, 2001 12:33 PM Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 > On Fri, 1 Jun 2001, Jeff Trawick wrote: > > > We finally died back in the main request processing because we > > referenced an mmap bucket whose apr_mmap_t used the same pool as the > > apr_file_t. The apr_mmap_t had been overlaid because the storage was > > released at the end of the main request and subsequently reused for > > some other purpose. > > ... > > Any ideas about what recent changes might have introduced or exposed > > this problem? > > Hmmm... ugly. It seems like a pretty basic design issue to me. No > changes were made between 2.0.16 and 2.0.18 to the buckets code itself > that would have affected this (there were only three substantive commits > to the buckets code in that time... two by me and one by Jeff... all > unrelated). If anything really did change in that time that broke this, > it's in Apache. > > --Cliff > > -------------------------------------------------------------- > Cliff Woolley > thomasstokes@example.com > Charlottesville, VA > > > From thomasstokes@example.com Fri Jun 01 17:48:45 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 87035 invoked by uid 500); 1 Jun 2001 17:48:42 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 87011 invoked from network); 1 Jun 2001 17:48:41 -0000 X-Authentication-Warning: cobra.cs.Virginia.EDU: jcw5q owned process doing -bs Date: Fri, 1 Jun 2001 13:48:42 -0400 (EDT) From: Cliff Woolley <thomasstokes@example.com> X-X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 1 Jun 2001, William A. Rowe, Jr. wrote: > Is this specific to a platform? Perhaps sendfile had been disabled in 2.0.16, > and was enabled by all the buildconf cleanup? That's an interesting thought. Although if MMAP buckets are involved somehow, that means that we've already read from the file, so sendfile() would not be used anyway. But something similar could be happening MMAP-wise... maybe APR_HAS_MMAP was off in the old build or something like that? --Cliff -------------------------------------------------------------- Cliff Woolley thomasstokes@example.com Charlottesville, VA From thomasstokes@example.com Fri Jun 01 17:54:37 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 1397 invoked by uid 500); 1 Jun 2001 17:54:34 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 1230 invoked from network); 1 Jun 2001 17:54:32 -0000 Date: Fri, 1 Jun 2001 10:57:02 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Cc: <thomasstokes@example.com> Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c In-Reply-To: <thomasstokes@example.com> Message-ID: <{{EMAIL+PHONE}}> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > +static void add_required_filters(request_rec *r) > +{ > + ap_filter_t *f = r->output_filters; > + int has_core = 0, has_content = 0, has_http_header = 0; > + while (f) { > + if(!strcasecmp(f->frec->name, "CORE")) > + has_core = 1; > + else if(!strcasecmp(f->frec->name, "CONTENT_LENGTH")) > + has_content = 1; > + else if(!strcasecmp(f->frec->name, "HTTP_HEADER")) > + has_http_header = 1; > + f = f->next; > + } > + if(!has_core) > + ap_add_output_filter("CORE", NULL, r, r->connection); > + if(!has_content) > + ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); > + if(!has_http_header) > + ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); > + > +} > + > /***************************************************************** > * > * Mainline request processing... > @@ -201,6 +223,7 @@ > custom_response); > } > } > + add_required_filters(r); > ap_send_error_response(r, recursive_error); > } This could be made MUCH simpler by just changing reset_filters to: void reset_filters(r) { ap_filter_t *f = r->output_filters; int has_core = 0, has_content = 0, has_http_header = 0; while (f) { ap_filter_t *f2 = f->next; ap_remove_filter(f); f = f2; } ap_add_output_filter("CORE", NULL, r, r->connection); ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); } This is slightly slower, but much easier to read and debug. And, this is an error condition, so who cares if we do three extra pointer manipulations? Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 17:57:37 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 6403 invoked by uid 500); 1 Jun 2001 17:57:37 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 6392 invoked from network); 1 Jun 2001 17:57:37 -0000 Date: Fri, 1 Jun 2001 11:00:08 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com>, <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 In-Reply-To: <thomasstokes@example.com> Message-ID: <{{EMAIL+PHONE}}> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 1 Jun 2001, Jeff Trawick wrote: > Greg Ames put together a 2.0.18 build for the purposes of running on > apache.org but we were never able to switch over to it from 2.0.16 > because of a hard failure with certain types of requests. > > The problem, trying to simplify a bit: > > In a subrequest, default_handler opens a file using the pool > associated with the subrequest and creates a file bucket. > > After the subrequest is over, we still have the file bucket with the > apr_file_t that had the now-destroyed pool. Any references to the > apr_file_t are broken because the pool was destroyed. > > We finally died back in the main request processing because we > referenced an mmap bucket whose apr_mmap_t used the same pool as the > apr_file_t. The apr_mmap_t had been overlaid because the storage was > released at the end of the main request and subsequently reused for > some other purpose. > > We have never hit this problem with 2.0.16 and we always hit this > problem with 2.0.18, leading me to believe that the problem was > affected by recent code changes, even though it seems to be a basic > design issue. > > Any ideas about what recent changes might have introduced or exposed > this problem? This is realitively simple. A while ago, I changed the default handler to use the connection pool to fix this problem. A couple of months ago, Dean pointed out that this was a major resource leak. After 2.0.16, somebody (Roy?) pointed out that this was a pretty big problem when serving a lot of very large files on the same connection. The solution was a simple loop at the end of the core_output_filter that reads in the data from the file to memory. This is okay to do, because we are garuanteed to have less than 9k of data. It sounds like the problem is that we don't read in the data if we have an MMAP, or we may not be getting into the loop on sub-requests. Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 17:58:09 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 7339 invoked by uid 500); 1 Jun 2001 17:58:07 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 7322 invoked from network); 1 Jun 2001 17:58:06 -0000 Sender: minfrin Message-ID: <thomasstokes@example.com> Date: Fri, 01 Jun 2001 19:07:01 +0200 From: Graham Leggett <thomasstokes@example.com> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.4 ppc) X-Accept-Language: en MIME-Version: 1.0 To: thomasstokes@example.com CC: thomasstokes@example.com Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c References: <{{EMAIL+PHONE}}> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA836DE574071C11DABA33C59" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This is a cryptographically signed message in MIME format. --------------msA836DE574071C11DABA33C59 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit thomasstokes@example.com wrote: > This could be made MUCH simpler by just changing reset_filters to: > > void reset_filters(r) > { > ap_filter_t *f = r->output_filters; > int has_core = 0, has_content = 0, has_http_header = 0; > while (f) { > ap_filter_t *f2 = f->next; > ap_remove_filter(f); > f = f2; > } > ap_add_output_filter("CORE", NULL, r, r->connection); > ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); > ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); > } Won't this cause a problem if one of these basic filters threw the error in the first place - when the filter was thrown away (and replaced) the context would be thrown away too. Would this be a problem, or am I missing something? Regards, Graham -- ----------------------------------------- thomasstokes@example.com "There's a moon over Bourbon Street tonight..." --------------msA836DE574071C11DABA33C59 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1MTEwMDE3NDZa MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UEAxMOR3JhaGFt IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5nR87bYWyLVCt XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsElnxYbRRA2SZc CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTArMBsGA1UdEQQU MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCO l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOVAk3LL1KTupvc HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4IMZbuH/rm0ZWp WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdEx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4 MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7Sbngn Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmF zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ 7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwx LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9Dps NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaW GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDYwMTE3MDcwMlowIwYJKoZIhvcN AQkEMRYEFJri4sLgH1rJ0rqrN50S08NnRe32MCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCUfKYuqqIkA+tYb6nWTp+iVIkSCVxJ yaJiam4XkGJYQY4OVgf7bG8Y35HAcKPIckqGUsREjJc1bniKVa3reGbjuDsAuAxnaGbmVET/ BNNRLzDA6s2KE4+ACXOTN7uGj9vw43O6fHThU11KVFkoPwe1uAG87oMciJawYCBaP6p8VQ== --------------msA836DE574071C11DABA33C59-- From thomasstokes@example.com Fri Jun 01 18:15:53 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 37474 invoked by uid 500); 1 Jun 2001 18:15:47 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 37355 invoked from network); 1 Jun 2001 18:15:46 -0000 Date: Fri, 1 Jun 2001 11:18:12 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Cc: <thomasstokes@example.com> Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c In-Reply-To: <thomasstokes@example.com> Message-ID: <{{EMAIL+PHONE}}> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 1 Jun 2001, Graham Leggett wrote: > thomasstokes@example.com wrote: > > > This could be made MUCH simpler by just changing reset_filters to: > > > > void reset_filters(r) > > { > > ap_filter_t *f = r->output_filters; > > int has_core = 0, has_content = 0, has_http_header = 0; > > while (f) { > > ap_filter_t *f2 = f->next; > > ap_remove_filter(f); > > f = f2; > > } > > ap_add_output_filter("CORE", NULL, r, r->connection); > > ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); > > ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); > > } > > Won't this cause a problem if one of these basic filters threw the error > in the first place - when the filter was thrown away (and replaced) the > context would be thrown away too. Would this be a problem, or am I > missing something? The error is completely owned by the stuff in the request_rec by now. There shouldn't be anything in any of these three filters that is saved in the context pointer that we actually need to send out a valid error response. Remember, that those filters are storing information about the valid response, once we find an error we basically have a completely different response that we are sending, and any old information in the filter is invalid. Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 18:22:17 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 46551 invoked by uid 500); 1 Jun 2001 18:22:12 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 46537 invoked from network); 1 Jun 2001 18:22:11 -0000 Sender: minfrin Message-ID: <thomasstokes@example.com> Date: Fri, 01 Jun 2001 19:31:02 +0200 From: Graham Leggett <thomasstokes@example.com> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.4 ppc) X-Accept-Language: en MIME-Version: 1.0 To: thomasstokes@example.com CC: thomasstokes@example.com Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c References: <{{EMAIL+PHONE}}> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD2310EA35701B3CCC56B8CD1" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N This is a cryptographically signed message in MIME format. --------------msD2310EA35701B3CCC56B8CD1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit thomasstokes@example.com wrote: > > > void reset_filters(r) > > > { > > > ap_filter_t *f = r->output_filters; > > > int has_core = 0, has_content = 0, has_http_header = 0; > > > while (f) { > > > ap_filter_t *f2 = f->next; > > > ap_remove_filter(f); > > > f = f2; > > > } > > > ap_add_output_filter("CORE", NULL, r, r->connection); > > > ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); > > > ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); > > > } > > > > Won't this cause a problem if one of these basic filters threw the error > > in the first place - when the filter was thrown away (and replaced) the > > context would be thrown away too. Would this be a problem, or am I > > missing something? > > The error is completely owned by the stuff in the request_rec by now. > There shouldn't be anything in any of these three filters that is saved in > the context pointer that we actually need to send out a valid error > response. Remember, that those filters are storing information about the > valid response, once we find an error we basically have a completely > different response that we are sending, and any old information in the > filter is invalid. Ok - so to sum up basically reset_filters() should remove all filters from the stack, then add the three minimal basic filters, and run with it from there...? Regards, Graham -- ----------------------------------------- thomasstokes@example.com "There's a moon over Bourbon Street tonight..." --------------msD2310EA35701B3CCC56B8CD1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHyAYJKoZIhvcNAQcCoIIHuTCCB7UCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcYwggKVMIIB/qADAgECAgMEyOwwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA1MTEwMDE3NDZaFw0wMjA1MTEwMDE3NDZa MF0xEDAOBgNVBAQTB0xlZ2dldHQxDzANBgNVBCoTBkdyYWhhbTEXMBUGA1UEAxMOR3JhaGFt IExlZ2dldHQxHzAdBgkqhkiG9w0BCQEWEG1pbmZyaW5Ac2hhcnAuZm0wgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALX2zJvQ/9l+sCEpkfMNNwtnMcF8vmPM2sRpibT5nR87bYWyLVCt XXWXU+UyDOkiQJt6UahnmYZV7u40a1/osbNnjHjyNybejOuUFjHYy1gDwjsElnxYbRRA2SZc CmrZ4V0QFI0ZKuimGryZQj77UroiIV+Qq+v+PaxDEGwiqJqnAgMBAAGjLTArMBsGA1UdEQQU MBKBEG1pbmZyaW5Ac2hhcnAuZm0wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCO l5bH8JXuFM+EZi01jfezzKML5iPBHx4BDj/4gl2lXw1t0v6o+9442F6TpnOVAk3LL1KTupvc HfM+Bn71iWuD8ASCoSsmVpeoCbOv3lPGltrDgywcmM8phZyK1hHLvvJgfd4IMZbuH/rm0ZWp WjRORFfik8yuO9DgahgjgAhkujCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdEx CzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24g U2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4 MzAwMDAwMDBaFw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT QSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7Sbngn Z4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmF zVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ 7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwx LTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOB gQBzG28mZYv/FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9Dps NJKs5pKcbsEjAcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaW GCVNavSdxcORL6mWuAU8Uvzd6WIDSDGCAcowggHGAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFs IEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwTI7DAJBgUrDgMCGgUAoIGGMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDYwMTE3MzEwM1owIwYJKoZIhvcN AQkEMRYEFPT72wnXEWN3PhhZV3c0FgqkUQrZMCcGCSqGSIb3DQEJDzEaMBgwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBmQQN1UP5SSUhGlL2x5x0Y5V5oQGNM abOK+CaXVsXkDlP7SqNJ3OPDtWuCesAaDfdln9Cy5km7udKrAj6isGsaT8DP6Hv3i3cnd3Ko 4n+bh86yMsO4JOipS5k/mob50imXKr8RoLpckQwHqhcqgAC85mQsbrI8rRDPpFwjQ0UAVg== --------------msD2310EA35701B3CCC56B8CD1-- From thomasstokes@example.com Fri Jun 01 18:30:58 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 50112 invoked by uid 500); 1 Jun 2001 18:27:13 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 48160 invoked from network); 1 Jun 2001 18:24:27 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f Sender: thomasstokes@example.com To: thomasstokes@example.com, "William A. Rowe, Jr." <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 References: <thomasstokes@example.com> <thomasstokes@example.com> From: Jeff Trawick <thomasstokes@example.com> Date: 01 Jun 2001 14:21:11 -0400 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N "William A. Rowe, Jr." <thomasstokes@example.com> writes: > Is this specific to a platform? Perhaps sendfile had been disabled in 2.0.16, > and was enabled by all the buildconf cleanup? I don't think so... both sendfile and mmap were enabled in the 2.0.16 build which works fine -- Jeff Trawick | thomasstokes@example.com | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From thomasstokes@example.com Fri Jun 01 18:35:43 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 53536 invoked by uid 500); 1 Jun 2001 18:32:10 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 51313 invoked from network); 1 Jun 2001 18:28:22 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f Sender: thomasstokes@example.com To: thomasstokes@example.com Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 References: <{{EMAIL+PHONE}}> From: Jeff Trawick <thomasstokes@example.com> Date: 01 Jun 2001 14:25:07 -0400 In-Reply-To: <{{EMAIL+PHONE}}> Message-ID: <thomasstokes@example.com> Lines: 54 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N <thomasstokes@example.com> writes: > On Fri, 1 Jun 2001, Jeff Trawick wrote: > > > Greg Ames put together a 2.0.18 build for the purposes of running on > > apache.org but we were never able to switch over to it from 2.0.16 > > because of a hard failure with certain types of requests. > > > > The problem, trying to simplify a bit: > > > > In a subrequest, default_handler opens a file using the pool > > associated with the subrequest and creates a file bucket. > > > > After the subrequest is over, we still have the file bucket with the > > apr_file_t that had the now-destroyed pool. Any references to the > > apr_file_t are broken because the pool was destroyed. > > > > We finally died back in the main request processing because we > > referenced an mmap bucket whose apr_mmap_t used the same pool as the > > apr_file_t. The apr_mmap_t had been overlaid because the storage was > > released at the end of the main request and subsequently reused for > > some other purpose. > > > > We have never hit this problem with 2.0.16 and we always hit this > > problem with 2.0.18, leading me to believe that the problem was > > affected by recent code changes, even though it seems to be a basic > > design issue. > > > > Any ideas about what recent changes might have introduced or exposed > > this problem? > > This is realitively simple. A while ago, I changed the default handler to > use the connection pool to fix this problem. A couple of months ago, Dean > pointed out that this was a major resource leak. After 2.0.16, somebody > (Roy?) pointed out that this was a pretty big problem when serving a lot > of very large files on the same connection. > > The solution was a simple loop at the end of the core_output_filter that > reads in the data from the file to memory. This is okay to do, because we > are garuanteed to have less than 9k of data. It sounds like the problem > is that we don't read in the data if we have an MMAP, or we may not be > getting into the loop on sub-requests. By "simple loop" do you mean the call to ap_save_brigade()? I haven't verified that we even get to that point on a subrequest, but my current guess is that we get to ap_save_brigade() but the setaside doesn't do anything for the mmap bucket because mmaps aren't normally transient. -- Jeff Trawick | thomasstokes@example.com | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From thomasstokes@example.com Fri Jun 01 18:35:43 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 54517 invoked by uid 500); 1 Jun 2001 18:33:50 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 51918 invoked from network); 1 Jun 2001 18:29:45 -0000 Date: Fri, 1 Jun 2001 11:32:07 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Cc: <thomasstokes@example.com> Subject: Re: cvs commit: httpd-2.0/modules/http http_request.c In-Reply-To: <thomasstokes@example.com> Message-ID: <{{EMAIL+PHONE}}> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On Fri, 1 Jun 2001, Graham Leggett wrote: > thomasstokes@example.com wrote: > > > > > void reset_filters(r) > > > > { > > > > ap_filter_t *f = r->output_filters; > > > > int has_core = 0, has_content = 0, has_http_header = 0; > > > > while (f) { > > > > ap_filter_t *f2 = f->next; > > > > ap_remove_filter(f); > > > > f = f2; > > > > } > > > > ap_add_output_filter("CORE", NULL, r, r->connection); > > > > ap_add_output_filter("CONTENT_LENGTH", NULL, r, r->connection); > > > > ap_add_output_filter("HTTP_HEADER", NULL, r, r->connection); > > > > } > > > > > > Won't this cause a problem if one of these basic filters threw the error > > > in the first place - when the filter was thrown away (and replaced) the > > > context would be thrown away too. Would this be a problem, or am I > > > missing something? > > > > The error is completely owned by the stuff in the request_rec by now. > > There shouldn't be anything in any of these three filters that is saved in > > the context pointer that we actually need to send out a valid error > > response. Remember, that those filters are storing information about the > > valid response, once we find an error we basically have a completely > > different response that we are sending, and any old information in the > > filter is invalid. > > Ok - so to sum up basically reset_filters() should remove all filters > from the stack, then add the three minimal basic filters, and run with > it from there...? Yep. Just makes the code easier by removing a bunch of if's. It also makes it very obvious just what the required filters are. If we ever need to add another required filter, it just gets added right there. Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 18:45:49 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 82202 invoked by uid 500); 1 Jun 2001 18:45:41 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 81981 invoked from network); 1 Jun 2001 18:45:37 -0000 Date: Fri, 1 Jun 2001 11:47:59 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N On 1 Jun 2001, Jeff Trawick wrote: > <thomasstokes@example.com> writes: > > > On Fri, 1 Jun 2001, Jeff Trawick wrote: > > > > > Greg Ames put together a 2.0.18 build for the purposes of running on > > > apache.org but we were never able to switch over to it from 2.0.16 > > > because of a hard failure with certain types of requests. > > > > > > The problem, trying to simplify a bit: > > > > > > In a subrequest, default_handler opens a file using the pool > > > associated with the subrequest and creates a file bucket. > > > > > > After the subrequest is over, we still have the file bucket with the > > > apr_file_t that had the now-destroyed pool. Any references to the > > > apr_file_t are broken because the pool was destroyed. > > > > > > We finally died back in the main request processing because we > > > referenced an mmap bucket whose apr_mmap_t used the same pool as the > > > apr_file_t. The apr_mmap_t had been overlaid because the storage was > > > released at the end of the main request and subsequently reused for > > > some other purpose. > > > > > > We have never hit this problem with 2.0.16 and we always hit this > > > problem with 2.0.18, leading me to believe that the problem was > > > affected by recent code changes, even though it seems to be a basic > > > design issue. > > > > > > Any ideas about what recent changes might have introduced or exposed > > > this problem? > > > > This is realitively simple. A while ago, I changed the default handler to > > use the connection pool to fix this problem. A couple of months ago, Dean > > pointed out that this was a major resource leak. After 2.0.16, somebody > > (Roy?) pointed out that this was a pretty big problem when serving a lot > > of very large files on the same connection. > > > > The solution was a simple loop at the end of the core_output_filter that > > reads in the data from the file to memory. This is okay to do, because we > > are garuanteed to have less than 9k of data. It sounds like the problem > > is that we don't read in the data if we have an MMAP, or we may not be > > getting into the loop on sub-requests. > > By "simple loop" do you mean the call to ap_save_brigade()? > > I haven't verified that we even get to that point on a subrequest, but > my current guess is that we get to ap_save_brigade() but the setaside > doesn't do anything for the mmap bucket because mmaps aren't normally > transient. Okay, I had a chance to look at the code, instead of going from memory. The code that is causing the problem is: if ((!fd && !more && (nbytes + flen < AP_MIN_BYTES_TO_WRITE) && !APR_BUCKET_IS_FLUSH(e)) || (nbytes + flen < AP_MIN_BYTES_TO_WRITE && APR_BUCKET_IS_EOS(e) && c->keepalive)) { /* NEVER save an EOS in here. If we are saving a brigade with * an EOS bucket, then we are doing keepalive connections, and * we want to process to second request fully. */ if (APR_BUCKET_IS_EOS(e)) { apr_bucket *bucket = NULL; /* If we are in here, then this request is a keepalive. We * need to be certain that any data in a bucket is valid * after the request_pool is cleared. */ if (ctx->b == NULL) { ctx->b = apr_brigade_create(f->c->pool); } APR_BRIGADE_FOREACH(bucket, b) { const char *str; apr_size_t n; rv = apr_bucket_read(bucket, &str, &n, APR_BLOCK_READ); /* This apr_brigade_write does not use a flush function because we assume that we will not write enough data into it to cause a flush. However, if we *do* write "too much", then we could end up with transient buckets which would suck. This works for now, but is a bit shaky if changes are made to some of the buffering sizes. Let's do an assert to prevent potential future problems... */ AP_DEBUG_ASSERT(AP_MIN_BYTES_TO_WRITE <= APR_BUCKET_BUFF_SIZE); apr_brigade_write(ctx->b, NULL, NULL, str, n); } apr_brigade_destroy(b); } else { ap_save_brigade(f, &ctx->b, &b); } return APR_SUCCESS; } This is meant to solve the problem, but we are only going into the loop that solves the problem if we see an EOS bucket. Of course, the sub-request filter is removing the EOS bucket. So, the solution IMO, is to do this same loop in the subreq_output_filter. Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 18:46:22 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 83917 invoked by uid 500); 1 Jun 2001 18:46:17 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 83795 invoked from network); 1 Jun 2001 18:46:15 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f Sender: thomasstokes@example.com To: thomasstokes@example.com Subject: Re: idle server processes not going away References: <thomasstokes@example.com> From: Jeff Trawick <thomasstokes@example.com> Date: 01 Jun 2001 14:42:55 -0400 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N <thomasstokes@example.com> writes: > As for the problem that Jeff is describing, this is a problem with trying > to make the old Apache 1.3 code fit the MPM model without paying enough > attention to the flow of the code. Take a look at the 1.3 code, it uses > longjmp to make sure it is always executing the correct code. The 2.0 > code tries to use return codes from APR functions. But, the basic code > still looks like the 1.3 code. A few months ago, child processes were > morphing into parent processes when we tried to kill them off. To fix > this, I modified some of the code to exit at the right time. I believe > about a month later, Paul Reder made a similar change. IMNSHO, this can > be solved only by actually taking the time to trace through the prefork > MPM, and figure out what is happening, and fixing the bugs. BTW, the > threaded and perchild MPMs are incredibly similar to the prefork MPM in > this respect. I'm not sure what you mean by "fixing the bugs." As I see it, prefork wants to use signals as the way to tell child processes to go away. Doing much in the signal handler is problematic. Instead we need to 1) longjmp() from the signal handler to a safe spot and exit from there or 2) we make sure we wake up when the signal handler returns. Do you have a third suggestion? I'll post a patch in the next few minutes for solution 2. It seems to work fine. -- Jeff Trawick | thomasstokes@example.com | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From thomasstokes@example.com Fri Jun 01 18:55:45 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 93607 invoked by uid 500); 1 Jun 2001 18:55:43 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 93518 invoked from network); 1 Jun 2001 18:55:42 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f Sender: thomasstokes@example.com To: thomasstokes@example.com Subject: [PATCH] get prefork MPM to wake up from accept mutex or select after signal From: Jeff Trawick <thomasstokes@example.com> Date: 01 Jun 2001 14:52:26 -0400 Message-ID: <thomasstokes@example.com> Lines: 201 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N If it checks the I_AM_TO_SHUTDOWN() macro when the mutex or select() returns EINTR then we are able to shut down idle server processes which are in select() or waiting to acquire the accept mutex. Certainly some polish is needed in prefork.c and some code for other platforms is needed in APR, but that is a minor detail. The important issue is whether or not to continue using signals for killing idle servers and if so how to exit once we are signalled. Some mildly disturbing issues are raised by this experiment: 1) apr_set_lock_interruptible() is Unix-specific AFAIK; either apr_set_lock_interruptible returns APR_ENOTIMPL everywhere else or we introduce APR_HAS_INTERRUPTIBLE_LOCKS or similar 2) apr_set_lock_interruptible() can't work when we are using pthread cross process locks as they don't do the EINTR thing Index: server/mpm/prefork/prefork.c =================================================================== RCS file: /home/cvs/httpd-2.0/server/mpm/prefork/prefork.c,v retrieving revision 1.175 diff -u -r1.175 prefork.c --- server/mpm/prefork/prefork.c 2001/05/15 02:38:15 1.175 +++ server/mpm/prefork/prefork.c 2001/06/01 17:49:54 @@ -272,14 +272,10 @@ ap_log_error(APLOG_MARK, APLOG_EMERG, rv, NULL, "couldn't create accept mutex"); exit(APEXIT_INIT); } -} - -static void accept_mutex_on(void) -{ - apr_status_t rv = apr_lock_acquire(accept_lock); - if (rv != APR_SUCCESS) { - ap_log_error(APLOG_MARK, APLOG_EMERG, rv, NULL, "couldn't grab the accept mutex"); - exit(APEXIT_CHILDFATAL); + rv = apr_lock_set_interruptible(accept_lock); + if (rv) { + ap_log_error(APLOG_MARK, APLOG_EMERG, rv, NULL, "couldn't make accept mutex interruptible"); + exit(APEXIT_INIT); } } @@ -581,6 +577,8 @@ apr_signal(SIGHUP, please_die_gracefully); ap_sync_scoreboard_image(); + + restart: while (!I_AM_TO_SHUTDOWN()) { /* Prepare to receive a SIGWINCH due to graceful restart so that @@ -609,7 +607,22 @@ */ /* Lock around "accept", if necessary */ - SAFE_ACCEPT(accept_mutex_on()); +#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT + if (ap_listeners->next) { +#endif + stat = apr_lock_acquire(accept_lock); + switch(stat) { + case APR_SUCCESS: + break; + case APR_EINTR: + continue; + default: + ap_log_error(APLOG_MARK, APLOG_EMERG, stat, NULL, "couldn't grab the accept mutex"); + exit(APEXIT_CHILDFATAL); + } +#ifdef SINGLE_LISTEN_UNSERIALIZED_ACCEPT + } +#endif for (;;) { if (ap_listeners->next) { @@ -617,7 +630,14 @@ memcpy(&main_fds, &listenfds, sizeof(fd_set)); srv = select(listenmaxfd + 1, &main_fds, NULL, NULL, NULL); - if (srv < 0 && errno != EINTR) { + if (srv <= 0) { + if (srv == 0) + continue; + else if (errno == EINTR) { + /* Go back to a point where we'll see if we should shut down. */ + SAFE_ACCEPT(accept_mutex_off()); + goto restart; + } /* Single Unix documents select as returning errnos * EBADF, EINTR, and EINVAL... and in none of those * cases does it make sense to continue. In fact @@ -627,9 +647,6 @@ ap_log_error(APLOG_MARK, APLOG_ERR, errno, ap_server_conf, "select: (listen)"); clean_child_exit(1); } - - if (srv <= 0) - continue; /* we remember the last_lr we searched last time around so that we don't end up starving any particular listening socket */ Index: srclib/apr/include/apr_lock.h =================================================================== RCS file: /home/cvs/apr/include/apr_lock.h,v retrieving revision 1.24 diff -u -r1.24 apr_lock.h --- srclib/apr/include/apr_lock.h 2001/05/31 03:29:53 1.24 +++ srclib/apr/include/apr_lock.h 2001/06/01 17:50:18 @@ -178,6 +178,8 @@ const char *key, apr_status_t (*cleanup)(void *)); +APR_DECLARE(apr_status_t) apr_lock_set_interruptible(apr_lock_t *lock); + #ifdef __cplusplus } #endif Index: srclib/apr/include/arch/unix/locks.h =================================================================== RCS file: /home/cvs/apr/include/arch/unix/locks.h,v retrieving revision 1.27 diff -u -r1.27 locks.h --- srclib/apr/include/arch/unix/locks.h 2001/05/31 03:29:54 1.27 +++ srclib/apr/include/arch/unix/locks.h 2001/06/01 17:50:24 @@ -134,6 +134,9 @@ pthread_rwlock_t rwlock; #endif #endif +#if !APR_USE_PROC_PTHREAD_SERIALIZE + int interruptible; +#endif /* At some point, we should do a scope for both inter and intra process * locking here. Something like pthread_mutex with PTHREAD_PROCESS_SHARED */ Index: srclib/apr/locks/unix/crossproc.c =================================================================== RCS file: /home/cvs/apr/locks/unix/crossproc.c,v retrieving revision 1.42 diff -u -r1.42 crossproc.c --- srclib/apr/locks/unix/crossproc.c 2001/02/23 20:29:07 1.42 +++ srclib/apr/locks/unix/crossproc.c 2001/06/01 17:50:29 @@ -110,7 +110,7 @@ do { rc = semop(lock->interproc, &op_on, 1); - } while (rc < 0 && errno == EINTR); + } while (rc < 0 && errno == EINTR && !lock->interruptible); if (rc < 0) { return errno; } @@ -326,7 +326,7 @@ do { rc = fcntl(lock->interproc, F_SETLKW, &lock_it); - } while (rc < 0 && errno == EINTR); + } while (rc < 0 && errno == EINTR && !lock->interruptible); if (rc < 0) { return errno; } @@ -406,7 +406,7 @@ do { rc = flock(lock->interproc, LOCK_EX); - } while (rc < 0 && errno == EINTR); + } while (rc < 0 && errno == EINTR && !lock->interruptible); if (rc < 0) { return errno; } Index: srclib/apr/locks/unix/locks.c =================================================================== RCS file: /home/cvs/apr/locks/unix/locks.c,v retrieving revision 1.47 diff -u -r1.47 locks.c --- srclib/apr/locks/unix/locks.c 2001/05/31 03:29:59 1.47 +++ srclib/apr/locks/unix/locks.c 2001/06/01 17:50:29 @@ -309,4 +309,17 @@ #endif return APR_SUCCESS; } - + +apr_status_t apr_lock_set_interruptible(apr_lock_t *lock) +{ + if (lock->scope != APR_CROSS_PROCESS) { + return APR_ENOTIMPL; + } + +#if APR_USE_PROC_PTHREAD_SERIALIZE + return APR_ENOTIMPL; +#else + lock->interruptible = 1; + return APR_SUCCESS; +#endif +} -- Jeff Trawick | thomasstokes@example.com | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien... From thomasstokes@example.com Fri Jun 01 19:16:41 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 23686 invoked by uid 500); 1 Jun 2001 19:16:33 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 23660 invoked from network); 1 Jun 2001 19:16:29 -0000 Date: Fri, 1 Jun 2001 12:18:50 -0700 (PDT) From: <thomasstokes@example.com> X-Sender: <thomasstokes@example.com> To: <thomasstokes@example.com> Subject: Re: idle server processes not going away In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > > As for the problem that Jeff is describing, this is a problem with trying > > to make the old Apache 1.3 code fit the MPM model without paying enough > > attention to the flow of the code. Take a look at the 1.3 code, it uses > > longjmp to make sure it is always executing the correct code. The 2.0 > > code tries to use return codes from APR functions. But, the basic code > > still looks like the 1.3 code. A few months ago, child processes were > > morphing into parent processes when we tried to kill them off. To fix > > this, I modified some of the code to exit at the right time. I believe > > about a month later, Paul Reder made a similar change. IMNSHO, this can > > be solved only by actually taking the time to trace through the prefork > > MPM, and figure out what is happening, and fixing the bugs. BTW, the > > threaded and perchild MPMs are incredibly similar to the prefork MPM in > > this respect. > > I'm not sure what you mean by "fixing the bugs." > > As I see it, prefork wants to use signals as the way to tell child > processes to go away. Doing much in the signal handler is > problematic. Instead we need to 1) longjmp() from the signal handler to > a safe spot and exit from there or 2) we make sure we wake up when the > signal handler returns. Do you have a third suggestion? > > I'll post a patch in the next few minutes for solution 2. It seems to > work fine. I think the only way to really solve this, is to look at how the longjmp() was used in 1.3 to ensure we died correctly. I would also suggest looking at how threaded dies. If the real problem is the signal handling, then I would suggest that Dean was correct about signals and daemons, and we should just remove all singals and use the pipe_of_death for all Unix MPMs. Assuming that locks are interuptable is not a good idea IMHO. Ryan _______________________________________________________________________________ Ryan Bloom thomasstokes@example.com 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From thomasstokes@example.com Fri Jun 01 19:38:00 2001 Return-Path: <thomasstokes@example.com> Delivered-To: thomasstokes@example.com Received: (qmail 54440 invoked by uid 500); 1 Jun 2001 19:37:52 -0000 Mailing-List: contact thomasstokes@example.com; run by ezmlm Precedence: bulk Reply-To: thomasstokes@example.com list-help: <mailto:thomasstokes@example.com> list-unsubscribe: <mailto:thomasstokes@example.com> list-post: <mailto:thomasstokes@example.com> Delivered-To: mailing list thomasstokes@example.com Received: (qmail 54363 invoked from network); 1 Jun 2001 19:37:50 -0000 X-Authentication-Warning: adsl-77-241-65.rdu.bellsouth.net: trawick set sender to thomasstokes@example.com using -f Sender: thomasstokes@example.com To: thomasstokes@example.com Subject: Re: file/mmap buckets, subrequests, pools, 2.0.18 References: <thomasstokes@example.com> From: Jeff Trawick <thomasstokes@example.com> Date: 01 Jun 2001 15:34:36 -0400 In-Reply-To: <thomasstokes@example.com> Message-ID: <thomasstokes@example.com> Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N <thomasstokes@example.com> writes: > Okay, I had a chance to look at the code, instead of going from memory. > The code that is causing the problem is: > > if ((!fd && !more && > (nbytes + flen < AP_MIN_BYTES_TO_WRITE) && > !APR_BUCKET_IS_FLUSH(e)) > || (nbytes + flen < AP_MIN_BYTES_TO_WRITE && > APR_BUCKET_IS_EOS(e) && c->keepalive)) { > /* NEVER save an EOS in here. If we are saving a brigade with > * an EOS bucket, then we are doing keepalive connections, and > * we want to process to second request fully. > */ > if (APR_BUCKET_IS_EOS(e)) { > apr_bucket *bucket = NULL; > /* If we are in here, then this request is a keepalive. > We > * need to be certain that any data in a bucket is valid > * after the request_pool is cleared. > */ > if (ctx->b == NULL) { > ctx->b = apr_brigade_create(f->c->pool); > } > > APR_BRIGADE_FOREACH(bucket, b) { > const char *str; > apr_size_t n; > > rv = apr_bucket_read(bucket, &str, &n, > APR_BLOCK_READ); > > /* This apr_brigade_write does not use a flush > function > because we assume that we will not write enough > data > into it to cause a flush. However, if we *do* write >
{'source': 'Apache Software Foundation Public Mail Archives'}