svn commit: r1759465 - /perl/Apache-SizeLimit/trunk/Makefile.PL

Author: stevehay Date: Tue Sep 6 17:23:12 2016 New Revision: 1759465 URL: http://svn.apache.org/viewvc?rev=1759465=rev Log: Update Makefile.PL as per r1759432 Modified: perl/Apache-SizeLimit/trunk/Makefile.PL Modified: perl/Apache-SizeLimit/trunk/Makefile.PL URL:

svn commit: r1759464 - /perl/Apache-Reload/trunk/Makefile.PL

Author: stevehay Date: Tue Sep 6 17:22:41 2016 New Revision: 1759464 URL: http://svn.apache.org/viewvc?rev=1759464=rev Log: Update Makefile.PL as per r1759432 Modified: perl/Apache-Reload/trunk/Makefile.PL Modified: perl/Apache-Reload/trunk/Makefile.PL URL:

svn commit: r1759463 - /perl/modperl/trunk/RELEASE

Author: stevehay Date: Tue Sep 6 17:21:42 2016 New Revision: 1759463 URL: http://svn.apache.org/viewvc?rev=1759463=rev Log: Update RELEASE as per r1759430 Note: The latter part of this document still needs updating, which I will do in due course when making 2.0.10. Modified:

svn commit: r1759462 - /perl/Apache-SizeLimit/trunk/RELEASE

Author: stevehay Date: Tue Sep 6 17:20:27 2016 New Revision: 1759462 URL: http://svn.apache.org/viewvc?rev=1759462=rev Log: Update RELEASE as per r1759430 Modified: perl/Apache-SizeLimit/trunk/RELEASE Modified: perl/Apache-SizeLimit/trunk/RELEASE URL:

svn commit: r1759461 - /perl/Apache-Reload/trunk/RELEASE

Author: stevehay Date: Tue Sep 6 17:19:37 2016 New Revision: 1759461 URL: http://svn.apache.org/viewvc?rev=1759461=rev Log: Update RELEASE as per r1759430 Modified: perl/Apache-Reload/trunk/RELEASE Modified: perl/Apache-Reload/trunk/RELEASE URL:

Re: Apparent memory leak

Sorry, I should have explained what I meant better. You would add a handler BEFORE the request gets to your regular application, so you catch the details of the request that dies. I mis-remembered about the access_log. I was actually thinking of a custom C module I used once that did this type of

Re: Apparent memory leak

If this is a memory leak, won't the last request to be sent to the mod_perl worker process be the last straw and not necessarily the culprit? What if the leak is in some library code that's used in every request? On Tue, Sep 6, 2016 at 12:43 PM, John Dunlap wrote: > My fear with

Re: Apparent memory leak

My fear with logging the complete data input is that it will make the problem worse for my customers because this problem is only happening on heavily loaded servers. I can't reproduce it locally. On Tue, Sep 6, 2016 at 11:26 AM, Perrin Harkins wrote: > Hi John, > > The key

Re: Apparent memory leak

Hi John, The key is usually finding out what the request was that caused it. You can add the pid to your access logging, or write a more complete mod_perl handler to log the complete data input along with the pid. Then you just go back and look at what it was after you see which process was

Re: [ANNOUNCE] Apache-Test 1.40 released

What is the project about? Why should I be interested in it? [rhetorical questions] The Announce emails are sent to people not on the developer or user lists. Most will have no idea what the project is about. So the e-mails should contain at least brief details of what the product does, and some

Apparent memory leak

The system load reported by the uptime command, on one of my servers, periodically spikes to 20-30 and then, shortly thereafter, I see this in dmesg: [2887460.393402] Out of memory: Kill process 12533 (/usr/sbin/apach) score 25 or sacrifice child [2887460.394880] Killed process 12533

[ANNOUNCE] Apache-Test 1.40 released

We are pleased to announce the release of Apache-Test 1.40. This release is now, or soon will be, available for download from your favourite CPAN mirror or you can find it at: https://metacpan.org/release/Apache-Test Checksums for this release are: MD5 = 78e059bccfa0c2f0297ff2fca591eca9