Re: [mp1] callback called exit (many times)
Am I right deducing, that I should attempt recompiling perl with -DEMERGENCY_SBRK? Try to, but this doesn't solve the original problem. You still have to try to narrow down the code that causes the problem. Using ab or a similar load tester might help to stress test. Using tools to prevent situations when the server runs out of memory is very important. See the online docs for more info. Using these tools should probably solve the problem altogether, without using any special compilation options. The memory problem itself is already diagnosed (some non-apache process allocated more than it was expected, therefore less memory remained for apache/modperl processes) and I will work on it. Nevertheless I'd like to improve apache behaviour in lack of memory conditions - if possible. Thanks for all the hints. -- ( Marcin Kasperski | In any large change, 1/3 will think it is great, 1/3 ) ( http://www.mk.w.pl | will think it is stupid, and 1/3 will wait (Reed) ) () ( Porady dla twrcw serwisw WWW: http://www.mk.w.pl/porady/porady_www )
Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Issac Goldstand wrote: I think I got it... I was under the understanding that each fireman could only hande 1 bucket at a time, but there could be up to as many buckets as firemen on the stack at any given time... Do you know why it's like that? a limitation of the current mpms, there is only one thread/process for the whole pipeline of stages (filters/handlers). You could benefit from a real pipelining on an SMP machine. In any case we rather discuss this on the list. Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our many buckets with firemen scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a constant flush + buffer filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Issac
Re: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... On the opposite, IMHO this is very ON topic, since that's the core of the 2.0. there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our many buckets with firemen scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. That's the real pipeline. But it'll be only useful if you have many CPUs. I remember reading somewhere, that on a single CPU sequential processing might be faster rather than pseudo-parallel, because of the context-switch overhead. Though admittedly it's much smaller with threads, but depends on the implementation. Now, nothing prevents you from developing your own mpm right now or at any time latter that will do what you want. It's actually much easier that it seems to be because a big chunk of functionality is abstacted away. So it's not like writing an Apache server from scratch. I admit that I haven't written my own mpm yet and that's the impression that I have from reading posts at httpd-dev. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. Yes and no. Remember that our perl interpreters live in a separate pool of threads, so if we can release them asap, they can go and serve more requests, while the filters do whatever they do. Since the perl interpreters don't reside on the same thread that serves the connection. Though you are correct that the response handler won't be released until the filters will be done. So we need to think of some trickery to release the response handler earlier. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a constant flush + buffer filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Sure, there is nothing wrong with front/end backend setup, it just makes things a bit more complicated to setup and maintain. So if we can provide an alternative solution that requires only one server, that would be cool. That's said let's worry first to get the core things working first and if you want to play with optimizations please go ahead and hack away :) __ 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
[patch] Apache::DB now works with 5.8.0+
To all those having problems with Apache::DB and perl 5.8.0+ (CC'ing all
those who have complained recently).
Try this patch:
--- Apache-DB-0.06/DB.pm.old 1999-10-12 07:50:33.0 +0800
+++ Apache-DB-0.06/DB.pm 2002-11-29 18:03:47.0 +0800
@@ -14,6 +14,7 @@
$Apache::Registry::MarkLine = 0;
sub init {
+*DB::DB = sub {} unless DB-can(DB); # temp definition for 5.8.0+
if(init_debugger()) {
warn [notice] Apache::DB initialized in child $$\n;
}
__
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: [mp 2.0] can not compile mp 1.99_07
Dipl.-Inform. Kai Hofmann wrote: I tried to compile 1.99_07 - but there is a definition of IoTYPE_WRONLY and IoTYPE_REONLY within the file apr_perlio.c which can not be resolved unter SuSE Linux 7.2 with Apache 2.0.43 I greped all includes without any success where these things will be defined - any hints? Last time I compiles 1.99_03 successfully. Thanks for the report Kai. Fixed in the current cvs. __ 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
Thread::Pool problem
A lot of time ago some of you help us and your contribution to our work has been very important. We use the Thread::Pool version 0.22 module in our system and it works very well (under solaris SunOS 5.8 sun4u sparc SUNW,UltraAX-i2). Now we have installed the new version 0.28 of the module under a Linux 2.4.x os with Perl 5.8.0 and apache 1.3.26/mod_perl 1.27 (the same configuration installed under SUN). If we include the use directive of the module, the following very strange error is reported by apache in the error log. -_- /usr/local/apache_1.3.26/bin/httpd: invalid option -- M Usage: /usr/local/apache_1.3.26/bin/httpd [-D name] [-d directory] [-f file] [-C directive] [-c directive] [-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T] [-F] Options: -D name : define a name for use in IfDefine name directives -d directory : specify an alternate initial ServerRoot -f file : specify an alternate ServerConfigFile -C directive : process directive before reading config files -c directive : process directive after reading config files -v : show version number -V : show compile settings -h : list available command line options (this page) -l : list compiled-in modules -L : list available configuration directives -S : show parsed settings (currently only vhost settings) -t : run syntax check for config files (with docroot check) -T : run syntax check for config files (without docroot check) -F : run main process in foreground, for process supervisors _-_ Can help us again? Regards, Lino .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR Istituto di Scienza e Tecnologie dell' Informazione A. Faedo Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 Fax +39 050 3153464 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Apache doesn't load anymore modules after mod_perl.so
I did a 'strace' through httpd and found that Embperl.so isn't loaded. This probably explains the error in the previous mail. After tinkering around a little, it turns out that the LoadModule directive in Apache's configuration isn't loading any modules after mod_perl.so has been loaded. This is the case with mod_perl-1.99_07 and mod_perl-1.99_06. But with mod_perl-1.99-05, it works (and the Embperl problem below is gone too). So perhaps something broke in mod_perl between 05 and 06? Regards, .lzs On Fri, 29 Nov 2002, Lai Zit Seng wrote: I am trying to install Embperl-2.0b8. I've installed a standard Apache 2.0.43 (just ./configure; make; make install) and mod_perl 1.99_07 (just perl Makefile.PL; make; make install). And then, Embperl-2.0b8. But the make test fails with this error: Starting httpd... [Fri Nov 29 18:29:53 2002] [warn] PassEnv variable ACTION_PREFIX was undefined Syntax error on line 49 of /home/nwadm/work/Embperl-2.0b8/test/conf/httpd.conf: Invalid command 'Embperl_UseEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any clues about what may be wrong? TIA.
mod_perl configuration for ISP/webhost (disabling mod_perl access for normal users)
i've read the [EMAIL PROTECTED] archive (mainly the security suggestion thread in nov 2000). it seems that quite a few people (including me, recently) want to install mod_perl. usually they need mod_perl because they want to write apache modules in perl instead of c (including me; i really hate writing c code). for example, i'm contemplating on writing a custom log handler; previously i'm doing custom logging via piped logs, but i think i want to move this inside the apache process. unfortunately, these people are unable to do so because mod_perl would expose the server internals to normal users. i glanced at the mod_perl 1.27 source code and saw that many perl commands are still set at OR_ALL (allowed in .htaccess). for example: PerlHandler, PerlRequire, PerlSetEnv, etc. in an ISP/shared webhosting environment this is unacceptable. in general they want cgi execution to be wrapped and users not having access to mod_perl at all via .htaccess. heck, i don't even want users to *be aware* that mod_perl is there. i want mod_perl to be available just for *me* (the webhost/isp admin). no Apache::Registry for them, no Perl*Handler, no nothing; since all of them are unsafe. so i'm proposing an ISP_MODE/WEBHOST_MODE/ADMIN_MODE (or whatever) configure option that if enabled will make most (all?) of the OR_ALL to RSRC_CONF. i will probably be producing a patch for our own needs internally. -- dave
Fwd: Red Hat's use of mod_perl
Thanks Chip, great info! please keep those coming, we will update the site once we have several of these new additions. The original request is here: http://use.perl.org/articles/02/11/29/1837238.shtml?tid=11 Original Message Subject: Red Hat's use of mod_perl Date: 29 Nov 2002 23:30:24 -0500 From: Chip Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hey Stas, Just saw your request on use.perl.org. Red Hat's main website, www.redhat.com, is a mod_perl site (mainly Apache::ASP). Also, the Red Hat Network's website, rhn.redhat.com, is pure mod_perl, using a custom templating system (which I'll release one day, as soon as I find time..). It's actually a fairly complicated use of mod_perl for a web application, totalling around 60k likes of perl. Hope this is useful, Chip -- Chip Turner [EMAIL PROTECTED] Red Hat, Inc. -- __ 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: Apache doesn't load anymore modules after mod_perl.so
Lai Zit Seng wrote: After tinkering around a little, it turns out that the LoadModule directive in Apache's configuration isn't loading any modules after mod_perl.so has been loaded. This is the case with mod_perl-1.99_07 and mod_perl-1.99_06. But with mod_perl-1.99-05, it works (and the Embperl Hi, it is OK again with 1.99-08:-) Juergen
