cvs commit: modperl-2.0/t/response/TestApache compat2.pm
dougm 02/04/06 17:25:14
Modified:t/response/TestApache compat2.pm
Log:
get rid of annoying unexpectedly succeeded messages:
apache/compat2..ok, 1/34 unexpectedly succeeded
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED).
Revision ChangesPath
1.3 +5 -5 modperl-2.0/t/response/TestApache/compat2.pm
Index: compat2.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestApache/compat2.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- compat2.pm29 Jan 2002 07:55:56 - 1.2
+++ compat2.pm7 Apr 2002 01:25:14 - 1.3
-24,7 +24,7
sub handler {
my $r = shift;
-plan $r, tests = 34, todo = [23];
+plan $r, tests = 33;
$r-send_http_header('text/plain');
-152,11 +152,11
$r-headers_out-{Content-length},
\$r-set_content_length($csize) w/ setting explicit size);
-$r-set_content_length();
+#$r-set_content_length();
# TODO
-ok t_cmp(0, # XXX: $r-finfo-csize is not available yet
- $r-headers_out-{Content-length},
- \$r-set_content_length() w/o setting explicit size);
+#ok t_cmp(0, # XXX: $r-finfo-csize is not available yet
+# $r-headers_out-{Content-length},
+# \$r-set_content_length() w/o setting explicit size);
# XXX: how to test etag?
t_debug \$r-set_etag;
cvs commit: modperl-2.0/examples/lib/Apache HelloWorld.pm
dougm 02/04/06 20:05:07 Modified:examples/lib/Apache HelloWorld.pm Log: fix example, add more config Revision ChangesPath 1.4 +10 -3 modperl-2.0/examples/lib/Apache/HelloWorld.pm Index: HelloWorld.pm === RCS file: /home/cvs/modperl-2.0/examples/lib/Apache/HelloWorld.pm,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- HelloWorld.pm 6 Apr 2002 03:18:22 - 1.3 +++ HelloWorld.pm 7 Apr 2002 04:05:07 - 1.4 -1,8 +1,15 package Apache::HelloWorld; +#LoadModule perl_module modules/mod_perl.so +#PerlSwitches -Mlib=modperl-2.0/examples/lib + +##optional +#PerlModule Apache2 +#PerlModule Apache::compat + #Location /hello-world -# SetHandler modperl -# PerlResponseHandler Apache::HelloWorld +#SetHandler modperl +#PerlResponseHandler Apache::HelloWorld #/Location use strict; -19,7 +26,7 $r-puts(__PACKAGE__); #print not yet implemented -return OK; +return Apache::OK; } 1;
cvs commit: modperl-2.0 Changes
dougm 02/04/06 20:39:10 Modified:.Changes Log: here goes nuthin Revision ChangesPath 1.2 +3 -1 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Changes 13 Apr 2000 07:03:35 - 1.1 +++ Changes 7 Apr 2002 04:39:09 - 1.2 -1 +1,3 -=item 1.99_01-dev \ No newline at end of file +=item 1.99_01 - April 6, 2002 + +First public release of mod_perl-2.0-tobe.
RE: mod_perl Cook Book
on Saturday, April 06, 2002 08:50 [EMAIL PROTECTED] (Jeff) wrote: I bought it two weeks ago, as a mod_perl newbie, and recommend it. I really like the cookbook style: 'You want to XXX' = snippet / recipe. If you already read Perl, it is fast and compact. I have had questions along the way [specific to the cookbook], but posting a question on this list gets an almost immediate response. Summation: Worth the money - buy it. I agree completely. I'm setting up a server on OS X having just got a network connection and it's been invaluable. It's definitely the book to buy _before_ the Eagle book. Have fun, Regards, Phil.
Re: Thanks and GoodBye
Dear John, on our SuSe 7.3 server I run the shipped ready-made installation of Apache/mod_perl using DSO. It works fine, no special problems so far. Please don't give up, it's worth another try! Ernest -- * * VIRTUALITAS Inc. * * ** * * European Consultant Office * http://www.virtualitas.net * * Internationales Handelszentrum * contact:Ernest Lergon * * Friedrichstraße 95 *mailto:[EMAIL PROTECTED] * * 10117 Berlin / Germany * ums:+49180528132130266 * * PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc
Re: mod_perl Cook Book
HI, There is a section on performance tuning which is fantastic ... it gives practical examples of how you can monitor memory usage etc and tips on how to serve maximum hits per second. In the past month I've been wavering about mod_perl and have considered moving to Java servlets but this book has reminded me of the benefits of mod_perl and I'm sticking with it. Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster. On Fri, 5 Apr 2002, Rasoul Hajikhani wrote: Hello folks, Has anyone purchased the mod_perl cook book from this list? If so, what do you think of it? Is it a good buy? Appreciate feed back. I have two copies, as the one at work keeps getting borrowed. I would say it's different to the Eagle book - it takes a different tack (which is kinda the point). I find both books useful - the Eagle book for explaining the Apache request cycle very clearly, and the Cookbook for explaining some of the nuances of mod_perl very clearly. Basically the Cookbook is much more about solving specific problems than the Eagle book, and as such is much more useful long term and short term, and I also found the explanations a bit clearer in the Cookbook. So I'd get both, but the Cookbook first if you're new to mod_perl, and then the Eagle book if you're still confused about some issues. I promised Geoff I would do a full review, and I'm doing an OS upgrade this weekend, so perhaps I'll get a chance to go over the bits of the book I've missed so far and post the review somewhere. --
RE: mod_perl Cook Book
At 09:59 AM 04/06/02 +0100, Phil Dobbin wrote: It's definitely the book to buy _before_ the Eagle book. No, buy both at the same time. I think the Eagle gives a really good foundation, and it's very enjoyable reading (regardless of what my wife says!). I still think the Eagle book is one of the best books on my bookshelf. I have a couple of Apache-specific books and I learned a lot more about Apache from the Eagle than those. The cook book has been a great addition. -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: proxy front to modperl back with 1.3.24
FYI, There is a patch this morning from the mod_proxy maintainer. http://marc.theaimsgroup.com/?l=apache-httpd-devm=101810478231242w=2 Ed On Fri, Apr 05, 2002 at 02:33:35PM -0800, ___cliff rayman___ wrote: i had trouble using a proxy front end to both a mod_perl and mod_php back end servers. this works fine for me at 1.3.23, so I reverted back to it. i copied the httpd.conf files from the 1.3.24 to my downgraded 1.3.23 and everything worked correctly on the first try. i was getting garbage characters before the first html or doctype tag, and a 0 character at the end. also, there was a delay before the connection would close. i tried turning keep alives off and on in the back end server, but i did not note a change in behavior i also tried some different buffer directives, including the new ProxyIOBufferSize. these garbage characters and delays were not present serving static content from the front end server, or when directly requesting content directly from either of the back end servers. i know they've made some mods to the proxy module, including support for HTTP/1.1, but i did not have time to research the exact cause of the problem. just a word of warning before someone spends hours in frustration, or perhaps someone can give me a tip if they've solved this problem. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
doubt on how long the cookbook will apply
I have the Eagle book but have not buyed the Cookbook yet. I wonder whether the way Perl modules are written nowadays is going to be significantly altered by Apache 2.0. If it won't, I'll definitely buy it this weekend. -- fxn
Re: doubt on how long the cookbook will apply
F.Xavier Noria wrote: I have the Eagle book but have not buyed the Cookbook yet. I wonder whether the way Perl modules are written nowadays is going to be significantly altered by Apache 2.0. If it won't, I'll definitely buy it this weekend. The short answer: You can run your old code unaltered A bit longer answer: Under prefork mpm (forked server) you only need to add use Apache::compat; in your startup file and 99.9% of the 1.x code will work the same, though some things may be a bit slower. See for incomplete details: http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/user/compat/compat.html http://perl.apache.org/preview/modperl-docs/dst_html/docs/2.0/api/mod_perl-2.0/Apache/compat.html Under worker mpm and other threaded mpms, if the code is not thread-safe (mostly on the C level) it won't work properly. The complete answer is under development, partly covered in the above URLs and will most likely be improved when modperl 2.0 gets released. You are welcome to help. Join the [EMAIL PROTECTED] list. In any case modperl 1.x is here to stay for a few years to come. It will take a while before the majority will move to 2.0. So the 1.x books are very relevant now and still be a year from now and even later. p.s. I didn't want to add to the noise with 'me too' in first place, but since I've replied to this, get both books: they'll save you a lot in the long run. Both books are great! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: sun4-solaris polluted installation
If you're doing a demo, then I'd advise against installing over the production distributions. Create your own perl and Apache's. Philippe Chiasson wrote a paper for either ApacheCon or PerlCon about managing multiple modperl developers. If I recall correctly, each developer had their own Perl and Apache's living in each user's home directory with a CVS checkout of the latest application code. Before they were rolled out in production, he could then test against his copy of the current production environment. John [EMAIL PROTECTED]
Re: sun4-solaris polluted installation
Hi there, On Fri, 5 Apr 2002, Slava Bizyayev wrote: Nice try. Unfortunately, helpless... Don't you see two instances of mod_perl in common perl libraries? That's just flowers... Are you sure you understood my message? I don't understand your reply but you seem to be a little frustrated. Running two instances of a mod_perl Apache does not necessarily require that you run the Apache nor mod_perl 'make install' twice (although you may wish to compile different Apache and/or mod_perl binaries). You just have to create a second configuration and start a second server. You can for example compile a mod_perl Apache in your home directory and run it without root permissions. You don't need to do anything at all to the system's Perl installation until you mean to run the mod_perl Apache in production, listening to port 80. In fact it's probably better if you don't. Did you get 'make test' to run ok before attempting 'make install'? 73, Ged.
Re: sun4-solaris polluted installation
Yes John, I would prefer never to stick with that prod too, indeed I have to. It's a business requirement in this case. The future contract depends on what the performance will be achieved on that sever. The customer does not care too much about the demo (made) on dev. They wish to measure the performance on prod exactly, using the real data. And, the customer is right (as always;-)... Thanks, Slava - Original Message - From: John D Groenveld [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 3:10 PM Subject: Re: sun4-solaris polluted installation If you're doing a demo, then I'd advise against installing over the production distributions. Create your own perl and Apache's. Philippe Chiasson wrote a paper for either ApacheCon or PerlCon about managing multiple modperl developers. If I recall correctly, each developer had their own Perl and Apache's living in each user's home directory with a CVS checkout of the latest application code. Before they were rolled out in production, he could then test against his copy of the current production environment. John [EMAIL PROTECTED]
Re: PDF generation
On Wed, Apr 03, 2002 at 03:43:39PM -0500, Bill McCabe took time to write: I have a large number of mod_perl modules that connect to various databases and generate workflow performance reports for my organization. I give the users 3 output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output I've been using PDF::Create, which has been at version .01 since 1999. It has worked flawlessly for my purposes for a couple of years, but is very limited. In fine form-follows-function fashion, the end users would now like the PDF output gussied up with graphics, etc. Does anyone have any strong (positive or negative) recommendations for which module(s) I should migrate to? I do not use Perl modules to do that, but LaTeX. As ugly as it may sound it enables to output very complex PDF files, exactly the way you want. More precisely I have LaTeX templates, I use CGI::FastTemplate to fill them in with dynamic data, run pdflatex, and then have a nice PDF file. Good luck in your search. Patrick.
Re: sun4-solaris polluted installation
Yes Ged, I always make test before make install. Even just make, when appropriate... The idea to make the independently installed mod_perl enabled Apache has failed on this machine several times (when the native sysadmin tried to do that). Now, I have to find out why it fails. I see the polluted file system and a lot of mess in common perl libraries. What of that could affect the installation? I would like to know. I see an odd behavior of the make install (what I've just never been seeing on my dev). It might be OK, or may be wrong. I'd like to know too. I'd like to obtain probably some extra ideas, what to check/care about in this situation... Is there anybody, who can understand what I'm writing about? Thanks, Slava - Original Message - From: Ged Haywood [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 4:12 PM Subject: Re: sun4-solaris polluted installation Hi there, On Fri, 5 Apr 2002, Slava Bizyayev wrote: Nice try. Unfortunately, helpless... Don't you see two instances of mod_perl in common perl libraries? That's just flowers... Are you sure you understood my message? I don't understand your reply but you seem to be a little frustrated. Running two instances of a mod_perl Apache does not necessarily require that you run the Apache nor mod_perl 'make install' twice (although you may wish to compile different Apache and/or mod_perl binaries). You just have to create a second configuration and start a second server. You can for example compile a mod_perl Apache in your home directory and run it without root permissions. You don't need to do anything at all to the system's Perl installation until you mean to run the mod_perl Apache in production, listening to port 80. In fact it's probably better if you don't. Did you get 'make test' to run ok before attempting 'make install'? 73, Ged.
Multiple Cookie Header Bug with Apache::ProxyRewrite
hello, Christian
I found a bug with how Apache::ProxyRewite handles cookies.
Our proxy server was trying to display a remote application that heavily uses cookies
butthe application was failing miserably.
I compared the headers of what the proxy server was sending to the client vs. what the
remote server was displaying. the proxy server was only sending one (the last one) of
4 Set-Cookie headers.
The problems lies in the way that all headers are set:
$r-headers_out-{$header} = $value;
I patched the server by changing sum code in: sub respond { }
to allow for multiple cookie headers.
Here is what I did:
# feed reponse back into our request_record
$response-scan(sub {
my ($header, $value) = _;
$r-log-debug(respond: OUT $header: $value);
if ($header =~ /^Set-Cookie/i) {
$value =~ /path=([^;]+)/i;
my $cookie_path = $1;
rewrite_url($r, $remote_site, \$cookie_path, $mapref);
$value =~ s/(path=)([^;]+)/$1$cookie_path/i;
# Multiple Cookie Patch added by amen
# 04/03/2002
$r-headers_out-add( 'Set-Cookie' = $value );
$r-log-debug(respond: OUT-MOD $header: $value);
} else {
$r-headers_out-{$header} = $value;
}
});
Makes sense :)
thanx for writing this,
-amen
BTW we are using version 0.15
mod_perl and open files limit
Hello. I develop now my first project on mod_perl. When we started to test this project on separate server we faced excess opened files limit problem. There are no other serious tasks on this server, only mysql with project databases and apache. During the work with web interface number of open files slowly grows and finally reaches OS limit. And this happens with only 2-3 users working with interface !!! If to restart apache number of open files comes back in norm, so I think that the problem roots in my way of mod_perl usage. My scripts use this modules: Apache::Registry, Apache::DBI, HTML::Embperl, Apache::Store::MySQL, Apache::Lock::File. There are 3 different persistent database connections per each httpd child process. OS: FreeBSD 4.3-RELEASE kern.maxfiles: 1064 -- that can be increased of course, but we need to be sure that number of open files will not grow unlimited httpd.conf: KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxRequestsPerChild 0 What kind of diagnostics can be done to find out what causes the problem? Mike Andreev
Re: install test fails
Hi, For what it's worth it, I always have to add use URI::URL; to the files: mod_perl-x.xx/t/internal/hooks.t mod_perl-x.xx/lib/Apache/test.pm mod_perl-x.xx/blib/Apache/test.pm then all tests work - apart from the ones skipped on my OS - as usual ;) Hope this helps // Nicolai - Original Message - From: terry mcintyre [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 1:49 AM Subject: install test fails Redhat Linux 7.2 Apache 1.3.24 Perl 5.6.1 mod-perl-1.26 make test fails with result: /usr/bin/perl t/TEST 0 Can't locate object method new via package URI::URL (perhaps you forgot to load URI::URL?) at ./blib/lib/Apache/test.pm line 252. make: *** [run_tests] Error 255 typescript with complete output follows: Any clues greatly appreciated. Thanks! __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: PDF generation (fwd)
I have had a tremendous amount of success with htmldoc. see: http://www.easysw.com/htmldoc/ (it's gpl'd and has fairly decent documentation). not a module, but can be easily called from cgi-bin, etc and handles formatting really well. you design your output in html and pass it to htmldoc and out comes a pdf. good luck jim willis -- Forwarded message -- Date: Wed, 3 Apr 2002 15:43:39 -0500 From: Bill McCabe [EMAIL PROTECTED] To: modperl [EMAIL PROTECTED] Subject: PDF generation Hi All I have a large number of mod_perl modules that connect to various databases and generate workflow performance reports for my organization. I give the users 3 output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output I've been using PDF::Create, which has been at version .01 since 1999. It has worked flawlessly for my purposes for a couple of years, but is very limited. In fine form-follows-function fashion, the end users would now like the PDF output gussied up with graphics, etc. Does anyone have any strong (positive or negative) recommendations for which module(s) I should migrate to? TIA, Bill --
RE: Thanks and GoodBye
Hi Jonathan, Yes, I even tried that. It got hung up on a missing install.sh file. Thanks John Kolvereid --- Jonathan M. Hollin [EMAIL PROTECTED] wrote: Thanks for all your help, but I am NOT able to install mod_perl. John, I don't know if anyone has mentioned this before, but have you tried the Apache Toolbox (http://www.apachetoolbox.com/)? Before you give up completely it might be worth trying. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/ http://wypug.digital-word.com/ __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: Thanks and GoodBye
Hi Perrin, I might try it later. Actually, I am a programmer and I would very much like to take advantage of the features that mod_perl offer. If all fails I'll drop back to CGI, JSP and PHP. Thanks. John Kolvereid --- Perrin Harkins [EMAIL PROTECTED] wrote: John Kolvereid wrote: Thanks for all your help, but I am NOT able to install mod_perl. It's probably something that is not installed on my particular server - I'll never know. I suspect you were just trying to do too much at once on your first try by throwing PHP and SSL in the mix. I suggest you look at SpeedyCGI (http://daemoninc.com/speedycgi/), which offers similar speedups for CGI scripts but does not require you to recompile Apache. It doesn't have the same feature set as mod_perl, but all you wanted to do was speed up your existing CGI scripts anyway. - Perrin __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Leak error
Hello again, I have noticed that when I try to build mod_perl I get a bunch of parse errors when the 'make' is in the ./Leak directory. Could this be the reason that I am unable to build mod_perl and ssl and php simultaneously. Please advise. Thanks. John Kolvereid __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: Leak error
Maybe - but not likely... If you think it's mod_perl causing problems - why don't you drop ssl and php for now (as suggested earlier)? Well - maybe even a just basic Apache to start with. If that works - move on and get mod_perl installed. When you are satisfied with that you can start looking into ssl and php. My current install is with mod_perl, mod_php, and mod_ssl, it all as DSO - and I am very unhappy with mod_perl being a DSO. I had many problems installing ssl together with mod_perl, so for the being I choose to make it DSO just to have something running. When I get some time again I will built in mod_perl in my httpd and maybe even ssl. PHP will stay as DSO I think... maybe I will try compile it into my httpd as well. The bottom line is: don't take your mouth ful... Start with basics... then slowly move on... you have to crawl before you walk - and so on ;) Best of luck again // Nicolai - Original Message - From: John Kolvereid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 7:08 PM Subject: Leak error Hello again, I have noticed that when I try to build mod_perl I get a bunch of parse errors when the 'make' is in the /Leak directory. Could this be the reason that I am unable to build mod_perl and ssl and php simultaneously. Please advise. Thanks. John Kolvereid __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Re: mod_perl and open files limit
On Thu, 2002-04-04 at 00:46, Mike V. Andreev wrote: Hello. hi. During the work with web interface number of open files slowly grows and finally reaches OS limit. And this happens with only 2-3 users working with interface !!! If to restart apache number of open files comes back in norm, so I think that the problem roots in my way of mod_perl usage. first of all, is your code closing all the filehandles it opens? garbage collection works differently in mod_perl, and unless you explicitly close fh's, they have the tendency to stay around for awhile. What kind of diagnostics can be done to find out what causes the problem? try lsof(8), which will list all open files (and the process they belong to). -jon -- [EMAIL PROTECTED] || www.divisionbyzero.com gpg key: www.divisionbyzero.com/pubkey.asc think i have a virus? www.divisionbyzero.com/pgp.html You are in a twisty little maze of Sendmail rules, all confusing. signature.asc Description: This is a digitally signed message part
[announce] mod_perl-1.99_01
The URL http://perl.apache.org/dist/mod_perl-1.99_01.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_01.tar.gz size: 368151 bytes md5: 8db81a4cc572544eb427f2beb1beceea This is the first public release of mod_perl version 2.0-tobe. Apache version 2.0.35 or higher is required. Perl version 5.6.0 or higher is required. mod_perl is currently considered beta when used with the prefork MPM. mod_perl is currently considered alpha when used with a threaded MPM. Only DSO build of mod_perl-2.0 is currently supported, static builds will be support in the future. mod_perl-2.0-tobe is not 100% feature complete with the 1.xx version. See the todo/ directory for what remains to be done. Comments, questions, bug-reports, etc., should be sent to the mod_perl users list: [EMAIL PROTECTED] Enjoy, -Doug
bug I think.
Apache/1.3.22 Ben-SSL/1.47 (Unix) DAV/1.0.3 mod_perl/1.26 The function getservbyport causes Apache to segfault when run from a terminal or as a normal cgi script it works fine when run with mod_perl it crashes. sample cgi is the part commented out. #!/usr/bin/perl my $proto = 'tcp'; my $proto = 'tcp'; my $name = getservbyport($port, $proto); #print EOF; #Content-type: text/html # #htmlbody bgcolor=#ff #$port, $name #/body #/html #EOF use Apache; my $r = Apache-request; my $html = q|html body bgcolor=#ff $port, $name /body /html |; $_ = length($html); $r-status(200); $r-content_type(text/html); $r-header_out(Content-length,$_); $r-send_http_header; $r-print ($html); return 200; # HTTP_OK
Re: mod_perl and open files limit
Hi there, On Wed, 3 Apr 2002, Mike V. Andreev wrote: files limit problem. httpd.conf: KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxRequestsPerChild 0 MaxClients? What kind of diagnostics can be done to find out what causes the problem? http://perl.apache.org/guide has a lot of useful pointers. I'd suggest setting MaxRequestsPerChild to a low value (I generally use something in the range of 50-100 but Perrin will tell you that's *very* low... :) to avoid leak problems. 73, Ged.
Re: mod_perl and open files limit
Hi again, On Thu, 4 Apr 2002, Mike V. Andreev wrote: MaxRequestsPerChild 0 -- if I set this limit to 10 then the problem disappear but that way deprives project of mod_perl usage advantages Not at all, for example 90 percent of your requests won't have to reload Perl. (Of course they won't all need to but the other ten percent will reload it anyway unless you're using a light front end... :). But even I wouldn't usually use a value as low as 10. Anyway, it looks like you're on the right track - probably a filehandle not being closed or something. Why not try using the Symbol::gensym technique as shown in the Guide, this closes filehandles automatically when they go out of scope. It works very well for me. 73, Ged. PS: BTW it's modperlatperldotapachedotorg now
