Installing mod_perl with ActiveState
Hi all I have just installed the binary of Apache v1.3.22 on Windows 2000 and have attempted to add mod_perl. I am using ActiveState Perl 5.6.1 The installation of mod_perl (from theoryx5.uwinnipeg.ca) via ppm fails when it attempts to install mod_perl.so to c:\apache root. The default location for apache when I installed it was c:\program files\apache group\apache. I followed the instructions and manually copied mod_perl.so to my modules directory. However, when I run apache -t I am warned of Invalid command 'PerlHander' in my startup.pl file. This suggests that mod_perl is not installed. ppm -query mod_perl suggests that it is installed correctly by ppm. I have tried installing and reinstalling, but to no avail. I have also entered: LoadModule perl_module modules/mod_perl.so in httpd.conf, which parses okay. Any ideas? Dan
Re: Installing mod_perl with ActiveState
The installation of mod_perl (from theoryx5.uwinnipeg.ca) via ppm fails when it attempts to install mod_perl.so to c:\apache root. The default location for apache when I installed it was c:\program files\apache group\apache. I followed the instructions and manually copied mod_perl.so to my modules directory. Does it now fails in Installtion or ... LoadModule perl_module modules/mod_perl.so in httpd.conf, which parses okay. ... does it parse OK? I used the above ingredients and the result was OK, from the scratch. I installed it in E:\Server\Apache, so no spaces. But this shouldn't be the problem? LoadModule perl_module modules/mod_perl.so AddModule mod_perl.c CU Christian
RE: Installing mod_perl with ActiveState
CU, cheers for this - 2 Things: 1. I reinstalled apache in c:/apache 2. I added AddModule mod_perl.c as you mentioned below. I did try with my old installation, but it didn't seem to parse. I don't know what was different this time other than my installation directory Thanks again Dan -Original Message- From: C.Hauser - IT assistance GmbH [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 9:49 PM To: Dan Horne Cc: [EMAIL PROTECTED] Subject: Re: Installing mod_perl with ActiveState The installation of mod_perl (from theoryx5.uwinnipeg.ca) via ppm fails when it attempts to install mod_perl.so to c:\apache root. The default location for apache when I installed it was c:\program files\apache group\apache. I followed the instructions and manually copied mod_perl.so to my modules directory. Does it now fails in Installtion or ... LoadModule perl_module modules/mod_perl.so in httpd.conf, which parses okay. ... does it parse OK? I used the above ingredients and the result was OK, from the scratch. I installed it in E:\Server\Apache, so no spaces. But this shouldn't be the problem? LoadModule perl_module modules/mod_perl.so AddModule mod_perl.c CU Christian
RE: Re[2]: Installing mod_perl with ActiveState
Sorry - I forgot to say that after I reinstalled apache in included AddModule mod_perl.c it all worked okay cheers Dan -Original Message- From: C.Hauser - IT assistance GmbH [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 10:09 PM To: Dan Horne Subject: Re[2]: Installing mod_perl with ActiveState So you call later PerlRequire E:/home/utils/startup.pl Might be there an error in startup.pl? == beginn original == Date: Donnerstag, 10. Januar 2002, 10:04:35 Subject: Installing mod_perl with ActiveState CU, cheers for this - 2 Things: 1. I reinstalled apache in c:/apache 2. I added AddModule mod_perl.c as you mentioned below. I did try with my old installation, but it didn't seem to parse. I don't know what was different this time other than my installation directory Thanks again Dan -Original Message- From: C.Hauser - IT assistance GmbH [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 10, 2002 9:49 PM To: Dan Horne Cc: [EMAIL PROTECTED] Subject: Re: Installing mod_perl with ActiveState The installation of mod_perl (from theoryx5.uwinnipeg.ca) via ppm fails when it attempts to install mod_perl.so to c:\apache root. The default location for apache when I installed it was c:\program files\apache group\apache. I followed the instructions and manually copied mod_perl.so to my modules directory. Does it now fails in Installtion or ... LoadModule perl_module modules/mod_perl.so in httpd.conf, which parses okay. ... does it parse OK? I used the above ingredients and the result was OK, from the scratch. I installed it in E:\Server\Apache, so no spaces. But this shouldn't be the problem? LoadModule perl_module modules/mod_perl.so AddModule mod_perl.c CU Christian === end original
Re: Altering ENV from a PerlFixupHandler
Benoit Caron wrote:
I'm trying to set a way of passing some environnement variables from my
front-end server to my back-end so that my Registry or PerlRun script run
unchanged. What I've done is that I've modified my frontend to add, with
mod_rewrite, the environnement data I need (REFERER and REMOTE_ADDR), and I
tried, on the backend server, to add the value I received in the
environnement, like that :
$ENV{$key} = $args{$key};
that probably won't work.
or also like that :
$r-subprocess_env($key, $new_value);
My problem is that my change are erased before I get to the Response phase,
no matter how I set the environnement.
try from a PerlPostReadRequestHandler instead. you may be running up
against some other mod_perl process. mod_perl will set up the
environment once per request - typically at the content generation
phase, but there are ways to force it to do so sooner.
that's about all I can think of at the moment...
--Geoff
Where did i go wrong? Do I need to add a PerlPassEnv in my httpd.conf? And,
then, one more place to edit if I want to pass a new Environnnement variables?
And, is that a good way to acheive that?
Re: Ip Address On Outbound
Not long ago, John Buwa proclaimed... I havea question on outbound ips. I am writing a program that a user can enter an address and a spider will go and retrieve only the information that was request and then display the results to the enquiring user. My question is though, i have grabed the users ip address as the initiator of the request and i would like to use that ip address (The users) to send the http request instead of my systems addres. How would i changed outgoing requests to reflect the invoking users ip and not my systems ip? Being as how the IP address is part of the TCP/IP protocols and not HTTP, I can't see how Apache (or mod_perl) can do anything about that. You can't spoof IPs at the application layer if you're doing network transactions. -=Fozz -- - Doran L. Barton [EMAIL PROTECTED] - Chief Super Hero - Iodynamics LLC http://www.iodynamics.com/ - Linux solutions and dynamic websites Pepsi brings your ancestors back from the grave. -- 'Pepsi Comes Alive' as originally translated into Chinese
Re: Apache and Perl togheter
El Mié 09 Ene 2002 10:00, Alan Civita escribió: Hello can some help me pelase? i've recently installed Apace 1.3.22...i've configured the CGI directive to work as well but when i try to execute a CGI script written in perl that message appears: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log The CGI script is a stupid test hello world CGI script ... Script written in sh script work. Can someone solve my problem please... Thx to all Alan As i understand what you are doing is nothing perl related, what you are using is apache module mod_cgi compiled in by default in apache. You must check if your script compiles and run from the shell: #cd youtscritpsdir #perl -wc myscript.pl #perl myscript.pl #chmod 755 myscript.pl #./myscript .pl If all this works you defionitely must check your error_log Hans Poo
Configuration loading twice - how to cope?
The Apache server processes its config file twice when starting up, and our code doesn't react well to that. On the first pass, everything initializes hunky-dorily (if that's a word), but on the second pass lots of stuff that is assumed to be loaded in memory doesn't work. This has been working just fine under our old setup, using Apache httpd version 1.3.14, mod_perl 1.24_01, and Perl 5.00503. But we're trying to upgrade to 1.3.22, 1.26, and 5.6.2 respectively, and now we have lots of problems. What I think I need to do is add some logic to test which pass we are currently running, and act according to that. Or are there any known bugs in Apache, mod_perl, or Perl that might be causing the trouble? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: Configuration loading twice - how to cope?
William R Ward wrote: The Apache server processes its config file twice when starting up, and our code doesn't react well to that. On the first pass, everything initializes hunky-dorily (if that's a word), but on the second pass lots of stuff that is assumed to be loaded in memory doesn't work. This has been working just fine under our old setup, using Apache httpd version 1.3.14, mod_perl 1.24_01, and Perl 5.00503. But we're trying to upgrade to 1.3.22, 1.26, and 5.6.2 respectively, and now we have lots of problems. hrm. the problem might not be the double-loading of httpd.conf then - that's been around since, well, before most of us (I tracked that down to apache 0.9 once through list archives) more likely is this: http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2 and the other reports in the archives that describe the same thing. What I think I need to do is add some logic to test which pass we are currently running, and act according to that. Or are there any known bugs in Apache, mod_perl, or Perl that might be causing the trouble? there is $Apache::Server::Starting, which is true only when the server is starting, which may be helpful to you. you may also want to consider putting your code in a PerlRestartHandler, which runs on restarts. since the second reading of httpd.conf is technically a restart for mod_perl, a PerlRestartHandler runs when you issue apachectl start or apachectl restart. HTH --Geoff
Re: Configuration loading twice - how to cope?
El Mié 09 Ene 2002 18:16, William R Ward escribió: The Apache server processes its config file twice when starting up, and our code doesn't react well to that. On the first pass, everything initializes hunky-dorily (if that's a word), but on the second pass lots of stuff that is assumed to be loaded in memory doesn't work. This has been working just fine under our old setup, using Apache httpd version 1.3.14, mod_perl 1.24_01, and Perl 5.00503. But we're trying to upgrade to 1.3.22, 1.26, and 5.6.2 respectively, and now we have lots of problems. What I think I need to do is add some logic to test which pass we are currently running, and act according to that. Or are there any known bugs in Apache, mod_perl, or Perl that might be causing the trouble? --Bill. I am not sure if i saw it in the eagle book, but as i remember apache make a fake checking start first after the real start of the server. This may be what you are seeing. Hans Poo
Re: Configuration loading twice - how to cope?
hrm. the problem might not be the double-loading of httpd.conf then - that's been around since, well, before most of us (I tracked that down to apache 0.9 once through list archives) more likely is this: http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2 and the other reports in the archives that describe the same thing. And my suggestion for dealing with that in the short term is to change your PerlModule directives to use Module; inside startup.pl or Perl sections. - Perrin
Alarms?
Hello!
I'm getting lots of errors in log:
[Thu Jan 10 18:54:33 2002] [notice] child pid 8532 exit signal Alarm clock
(14)
[Thu Jan 10 18:54:37 2002] [notice] child pid 8542 exit signal Alarm clock
(14)
[Thu Jan 10 18:54:42 2002] [notice] child pid 8537 exit signal Alarm clock
(14)
What causes that alarm? What does that alarm mean (I'm asking NOT about
signal itself, but about purpose)? How can I prevent that alarm from killing
running processes in the middle of processing?
I've set up $sig{ALRM} in handler.pl, but it does not get called.
Alex.
Apache::Reload question
Can Apache::Reload be used to reload modules that are use-d by httpd PerlModule, PerlRequire, or PerlHandler directives, or do they have to be explicitly use-d in code that is inside a handler? I think the answer is yes - these are no different than anything else except that memory sharing is lost because reload occurs in the children but wanted to check before I go down that path. Matthew Pressly
Re: mod_perl framework + code reuse question
At 09:09 PM 1/9/2002 -0500, Perrin Harkins wrote: Normal Perl rules apply. Modules are good for sharing code. You could stuff the shared parts into a sub in a module that every script would call. Or you could use an OO approach, with a base class that holds all of the boiler-plate stuff. The question I'm having a hard time answering without going down both paths is: What are the basic advantages, disadvantages, and limitations of: (a) stuffing all this setup/framework code into a module (either a new module or subclassing Apache::RegistryNG as you mention below), versus, (b) stuffing it into a handler that all requests for a large subset of the pages on this site have to go? Both approaches achieve the same result of funnelling all requests through a common set of code, which is mainly what I'm trying to achieve, but other than being different implementations, I'm not real clear on how they differ. It would seem like the put framework in a module approach might be more flexible (esp. subclassing Apache::RegistryNG) because different scripts could take-it-or-leave-it or even modify it through further subclassing. On the other hand, then common framwork in a handler approach might be faster because it could do just what is needed by all pages but nothing more, and as long as there is not too much code wasted by differences in the needs of different scripts, it could be that less code is being loaded and executed. Am I missing other things here? One idea I had was to write a handler that acts as a sort of minimal application framework that contains the code below and determines what perl module should be required and executed based on $apache-path_info and $apache-uri. That's a good way to go too. Moving from Apache::Registry to handlers can be empowering. Other than the speedup from reduced overhead, what are the primary advantages to using handlers rather than Apache::Registry for content handlers? The primary disadvantage seems to be that I have to restart httpd an awful lot, but maybe Apache::Reload can help here. Can it be used to reload modules that implement handlers? This sounds like a substantial effort Only if your code currently depends on the CGI emulation features of Apache::Registry. If it's clean code, you should be able to convert it without much trouble. You could also try subclassing Apache::RegistryNG and adding your setup code to the beginning of each request there. I will look into subclassing Apache::RegistryNG. This could be useful for other things as well. Maybe this is easier than what I'm picturing. I was thinking that writing the handler would be most of the effort, but it may be that it is mostly just designing an appropriate interface between the handler and the page code, re-partitioning the common code out of the pages and into the handler, and writing a simple dispatcher. Probably the biggest piece is the careful interface design so that future framework enhancements don't require changing old page code. I'd appreciate any input on how other people are structuring similar type applications in mod_perl, where the output is generated by Template Toolkit based on data obtained via SQL queries using parameters received mostly in the URL. I use handlers, with a model-view-controller design. The approach is documented in my Perl.com article about the eToys design. I keep all the common setup stuff in a base class that the other controllers inherit from. This is a very helpful article. I have read it several times and still keep coming back to it. I would also like to learn more about the model-view-controller approach in general. - Perrin Matthew Pressly
Re: Alarms?
At 06:56 PM 01/10/02 +0300, [EMAIL PROTECTED] wrote: Hello! I'm getting lots of errors in log: [Thu Jan 10 18:54:33 2002] [notice] child pid 8532 exit signal Alarm clock (14) I hope I remember this correctly: What's happening is you are setting a SIGALRM handler in perl, but perl is not correctly restoring Apache's handler when yours goes out of scope. So then a non-mod_perl request times out there's not handler and the process is killed. Check: http://thingy.kcilink.com/modperlguide/debug/Debugging_Signal_Handlers_SIG_.html http://thingy.kcilink.com/modperlguide/debug/Handling_Server_Timeout_Cases_an.html -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: mod_perl framework + code reuse question
What are the basic advantages, disadvantages, and limitations of: (a) stuffing all this setup/framework code into a module (either a new module or subclassing Apache::RegistryNG as you mention below), versus, (b) stuffing it into a handler that all requests for a large subset of the pages on this site have to go? Subclassing RegistryNG is pretty much identical to making your own handler. In both cases, you have some common code that runs on every request and then it decides what other code should be run to handle this specific action. In my opinion it's clearer this way than if you make a module with the init code and call it explicitly, but I can't think of a very good technical argument for it. The handler/RegistryNG approach lets you do neat things with subclassing, like create a special subclass that does some additional setup for a certain group of scripts. That wouldn't be as clean if you use the init module approach, since you'd have different scripts calling different init modules. Other than the speedup from reduced overhead, what are the primary advantages to using handlers rather than Apache::Registry for content handlers? You can actually use subroutines without fear! Also, reducing the amount of magic (i.e. all of that package generation and eval stuff that Registry does) can help clear up confusion. And you can use __END__ and __DATA__. The big change in moving from Registry (or RegistryNG) to a handler is that you have to move your code from the main part of the script into a subroutine and turn the script into a proper module. There's good stuff on this in the guide. The primary disadvantage seems to be that I have to restart httpd an awful lot, but maybe Apache::Reload can help here. Can it be used to reload modules that implement handlers? Yes, it should cover your needs. This is a very helpful article. I have read it several times and still keep coming back to it. I would also like to learn more about the model-view-controller approach in general. A Google search will give you tons to read, but most of it refers to Java. It's all applicable to mod_perl though. - Perrin
Questions on note_basic_auth_failure and get_basic_auth_pw
Documentation for these functions reads as follows: $r-get_basic_auth_pw If the current request is protected by Basic authentication, this method will return 0, otherwise -1. [snip] $r-note_basic_auth_failure Prior to requiring Basic authentication from the client, this method will set the outgoing HTTP headers asking the client to authenticate for the realm defined by the configuration directive `AuthName'. Experiments have shown that in an AuthenHandler, get_basic_auth_pw will return AUTH_REQUIRED if the request is protected and the client did not send credentials. Furthermore, note_basic_auth_failure seems to have no effect on the realm name. ### httpd.conf snippet; names changed to protect the innocent ### PerlRequire /home/www/perl/mod_perl_startup.pl PerlFreshRestart On Directory /home/www/htdocs/secret SetHandler perl-script # This module is use lib'd and use'd by the startup script PerlAuthenHandler Secret::Authen PerlHandler Apache::Registry PerlSendHeader Off AuthType Basic AuthName Secret Subtree Require valid-user /Directory ### /httpd.conf ### I was editing the module (Secret::Authen) and restarting both Mozilla and the server between trials. PerlFreshRestart was reloading the module as advertised; this was verified by a `warn' statement that told whether note_basic_auth_failure was executed or skipped. In both cases, Mozilla brought up a password dialog for the realm Secret Subtree. Also in both cases, multiple Reloads of the page did not require re-entering the password. So what does note_basic_auth_failure *really* do? Finally, I want to fix the get_basic_auth_pw documentation. Where should patches go for that, and in what format? System information: From vendor (RedHat 7.0) RPM: Perl/5.6.0 From source: mod_perl/1.26, apache/1.3.20, linux/2.4.16 From binary: mozilla/0.9.5 (x86 Linux full installer) = C. A. Sapphire Cat Daelhousen You can love me or hate me, but it won't change who I am. My opinions are my own, until UB purchases my soul. __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
Re: Configuration loading twice - how to cope?
Geoffrey Young [EMAIL PROTECTED] writes: William R Ward wrote: The Apache server processes its config file twice when starting up, and our code doesn't react well to that. On the first pass, everything initializes hunky-dorily (if that's a word), but on the second pass lots of stuff that is assumed to be loaded in memory doesn't work. This has been working just fine under our old setup, using Apache httpd version 1.3.14, mod_perl 1.24_01, and Perl 5.00503. But we're trying to upgrade to 1.3.22, 1.26, and 5.6.2 respectively, and now we have lots of problems. hrm. the problem might not be the double-loading of httpd.conf then - that's been around since, well, before most of us (I tracked that down to apache 0.9 once through list archives) more likely is this: http://marc.theaimsgroup.com/?l=apache-modperlm=100510779912574w=2 and the other reports in the archives that describe the same thing. Thanks for the tip, but I looked at that article and it doesn't appear to offer a solution, just more questions. It says the problem is fixed in version 1.26, but I still see the problem even with that version. What I think I need to do is add some logic to test which pass we are currently running, and act according to that. Or are there any known bugs in Apache, mod_perl, or Perl that might be causing the trouble? there is $Apache::Server::Starting, which is true only when the server is starting, which may be helpful to you. you may also want to consider putting your code in a PerlRestartHandler, which runs on restarts. since the second reading of httpd.conf is technically a restart for mod_perl, a PerlRestartHandler runs when you issue apachectl start or apachectl restart. I'll try these. Thanks. --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Problem building mod_perl 1.26
This is weird... anyone ever seen this before? In the middle of compiling the modules, I get syntax errors in the C code?? --Bill. /opt/SUNWspro/bin/cc -c -I/usr/local/include -O-DVERSION=\1.00\ -DXS_VERSION=\1.00\ -KPIC -I/usr/local/lib/perl5/5.00503/sun4-solaris/CORE Leak.c Leak.c, line 165: undefined symbol: aTHX_ Leak.c, line 165: syntax error before or at: Usage: Apache::Leak::NoteSV(obj) Leak.c, line 169: undefined symbol: dXSTARG Leak.c, line 176: undefined symbol: XSprePUSH Leak.c, line 176: undefined symbol: targ Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: left operand of - must be pointer to struct/union Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: warning: improper pointer/integer combination: op = Leak.c, line 185: undefined symbol: aTHX_ Leak.c, line 185: syntax error before or at: Usage: Apache::Leak::CheckSV(obj) Leak.c, line 187: syntax error before or at: hash_ptr Leak.c, line 189: undefined symbol: dXSTARG Leak.xs, line 171: undefined symbol: RETVAL Leak.c, line 194: undefined symbol: XSprePUSH Leak.c, line 194: undefined symbol: targ Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: left operand of - must be pointer to struct/union Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: warning: improper pointer/integer combination: op = Leak.c, line 203: undefined symbol: aTHX_ Leak.c, line 203: syntax error before or at: Usage: Apache::Leak::check_arenas() cc: acomp failed for Leak.c -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
mod_perl in the Open Directory (www.dmoz.org)
Hi, I was recently accepted as the editor for the mod_perl category of the Open Directory Project. The ODP is an all volunteer effort to build a directory of the web. Check it out at http://dmoz.org or any number of other services that use the underlying database (AOL, Google, etc.) The mod_perl category is available at: http://dmoz.org/Computers/Software/Internet/Servers/WWW/Apache/Modules/Mod_Perl/ By expanding this category our community can do a lot to help promote mod_perl. The ODP is used by many search engines, and you'll notice Google uses it for it's search results. I'm looking forward to building up the database of links. I have a number of my own favorites, but I'd like to hear from the rest of the community. If you have a mod_perl related site please submit it at: http://dmoz.org/cgi-bin/add.cgi?where=Computers/Software/Internet/Servers/WWW/Apache/Modules/Mod_Perl I'll edit through the submissions and craft a nice new structure (probably similar to the way the PHP category is organized). Proposed categories are: Directories Documentation and FAQs Toolkits Modules I may reorganize these based on the breadth of submissions offerred. Thanks! -- Paul Lindner[EMAIL PROTECTED] | | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: Problem building mod_perl 1.26
Nevermind - I did a make distclean and started over, and now the problem's gone. I still wonder what it means though. --Bill. William R Ward writes: This is weird... anyone ever seen this before? In the middle of compiling the modules, I get syntax errors in the C code?? --Bill. /opt/SUNWspro/bin/cc -c -I/usr/local/include -O-DVERSION=\1.00\ -DXS_VERSION=\1.00\ -KPIC -I/usr/local/lib/perl5/5.00503/sun4-solaris/CORE Leak.c Leak.c, line 165: undefined symbol: aTHX_ Leak.c, line 165: syntax error before or at: Usage: Apache::Leak::NoteSV(obj) Leak.c, line 169: undefined symbol: dXSTARG Leak.c, line 176: undefined symbol: XSprePUSH Leak.c, line 176: undefined symbol: targ Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: left operand of - must be pointer to struct/union Leak.c, line 176: warning: improper pointer/integer combination: arg #1 Leak.c, line 176: warning: improper pointer/integer combination: op = Leak.c, line 185: undefined symbol: aTHX_ Leak.c, line 185: syntax error before or at: Usage: Apache::Leak::CheckSV(obj) Leak.c, line 187: syntax error before or at: hash_ptr Leak.c, line 189: undefined symbol: dXSTARG Leak.xs, line 171: undefined symbol: RETVAL Leak.c, line 194: undefined symbol: XSprePUSH Leak.c, line 194: undefined symbol: targ Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: left operand of - must be pointer to struct/union Leak.c, line 194: warning: improper pointer/integer combination: arg #1 Leak.c, line 194: warning: improper pointer/integer combination: op = Leak.c, line 203: undefined symbol: aTHX_ Leak.c, line 203: syntax error before or at: Usage: Apache::Leak::check_arenas() cc: acomp failed for Leak.c -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - If you're not part of the solution, you're part of the precipitate.
Re: BSD::Resource und apache/mod_perl
Perrin Harkins wrote: The difference is that Apache::Resource should apply this limit to each new child process. When you do this from the shell, you are limiting the parent Apache process, which isn't very useful. I put use BSD::Resource; setrlimit RLIMIT_AS, 3200, 6400; at the top of the script which should be limited. So only the Apache child process of this script is limited. Are you sure you're using the right units (bytes vs. megabytes)? Could Yes, setrlimit wants bytes, Apache::Resource wants MBytes. your server be immediately going higher than the limit you set for it? Mmh, but what could be the reason? A normal httpd process has i.g. 8 MB and i set the limit to 32 MB. If I run the test script without setrlimit and watch it with top it slowly consumes the RAM appr. 1 MB / sec... Anyway: I still don't know what the reason was for this problem - but I solved it with installing a brand new apache, perl mod_perl - now it works as it should! ;-) Thanx for your help nonetheless!! - Perrin Best regards, Christoph
testing server response time
I was trying to test the CGI response time of a
Perl/CGI script under two conditions: as multiple
modules versus a single big script. First I installed
IndigoPerl (from indigostar.com) on my Windows machine
(which has an integrated apache server with mod_perl
enabled by default). Then I ran this script locally
against the local server:
#!/usr/local/bin/perl
use strict;
use LWP::Simple;
use Time::HiRes;
my $script = $ARGV[0];
my $totalTime = 0;
my $i; for ($i=0; $i 20; $i++) {
my $before = Time::HiRes::gettimeofday();
if ( $script eq 'big' ) {
print Running big: ;
if ( !defined( my $content =
LWP::Simple::get('http://localhost/cgi-bin/bigtool.cgi')))
{
print failed get\n;
}
} else {
if ( !defined( my $content =
LWP::Simple::get('http://localhost/cgi-bin/webtool.cgi')))
{
print failed get\n; }
}
my $elapsed = Time::HiRes::gettimeofday() -
$before;
print did $i in $elapsed seconds.\n;
$totalTime = $totalTime + $elapsed;
}
$totalTime = $totalTime / 20;
print Average response time for 20 requests was:
$totalTime seconds.\n;
end of script #
After I set up my app (webtool.cgi) and created the
single script version (bigtool.cgi), I ran this script
on my machine and it showed that the single file was
about 10-15% faster than the multiple modules.
My first question is, is the above script a valid test
of CGI response time? So, for example, should the
results reflect any improvements with mod_perl
enabled? Because what I found is that the response
time differed
less than 5% between mod_perl-enabled and mod_perl
disabled configurations.
The CGI application I'm testing this on is about 4,100
lines of Perl, and 114k bytes.
I emailed support@indigostar, but it's been over two
days and no reply yet. I figure I'd just throw this
out
there for feedback. From other postings, it seems like
Windows mod_perl works great, and I should see a
significant speed-up.
btw, I'm running Windows 98 SE on a 500 MHz machine.
Here's another test I did: I ran my test script
remotely against my local IndigoPerl server
from my remote unix account on sourceforge (because
I thought maybe an interaction between the test
script and the server running on the same machine).
Basically, it shows the same results: enabling
mod_perl only improves performance about 0-5%. I
even tried this timing test against the simple
one-line
'hellocgi.pl' script that came with IndigoPerl, and
it's response is also similar with or without mod_perl
(0.47 sec versus 0.54 seconds).
Here's the thing I discoved in doing this though: when
mod_perl is enabled, the disk indicator on my machine
does not blink on when running the remote test script;
with mod_perl disabled, the light blinks! So this
would indicate that mod_perl is getting enabled
and is 'working', not going to disk for requests...
unfortunately, it doesn't seem to improve the overall
response time much.
Comments? I'm certainly hoping that either this isn't
a valid test, or that IndigoPerl is just broken...
-alan
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
ANNOUNCE: Bricolage 1.2.0
I'd like to announce the release of Bricolage 1.2.0. It will shortly be available for download from http://bricolage.sourceforge.net/. This release features several bug fixes and quite a few important new features. It uses HTML::Mason exlusively for its UI, and uses either HTML::Mason or HTML::Template for its templating architecture. Here's a brief description of Bricolage: Bricolage is a full-featured, enterprise-class content management system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete programming language support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Here's a list of the changes from 1.0.2: VERSION 1.2.0 New Features * Added Context-sensitive, online help. [Sam] * Added separate interface for editing templates (via FTP). [Sam] * Added the ability to use HTML::Template Templates. [Sam] * Added ability for differnt Output Channels to function as different component roots for in Mason templates. This will allow for templates that can't be found in the current Output Channel to be searched for in other Output Channels. [David] * Added link to Event log to Find Story, Find Template, and Find Media screens. [David] * Added true previewing for media assets. Now, when you click their URIs to preview them, they will be distributed to the preview server(s) before redirecting the user to them, rather than just serving them up from where they live on the Bricolage file system. The latter can still be accessed under Download in the Media Asset profile. This will continue to be the preferred way to grab media files for editing and such, as it will not incur the overhead of distributing the media file. [David] * Allow only one template with a given name for a given category, element, burner and output channel. [Sam] * Added a Maintainer section to the About page. [David] * Updated About page to mimic the layout of the help pages. [David] Bug Fixes * Fixed a bug with local previews where a preview page could show up instead of the Bricoalge UI. Thanks to Sara for the spot. [David] * Fixed a bug where Mason component calls failed in previews when the PREVIEW_MASON directive was enabled. [David] * Changed default value for text area fields added via the form builder (i.e., in Contributor Type and Element profiles) to 0. The values 0 and always make the the new field unlimited in length. [David] * Fixed a couple of buttons to be proper case rather than upper case. [David] * Separated the filesystem destinations for assets burned for publication and for assets burned for previewing. This will prevent someone previewing and stomping all over a published version of an asset before the published version is distributed. [David] * Removed hard-coding of the local preview directory in httpd.conf and httpd-ssl.conf. Now using the values stored in PREVIEW_LOCAL, instead, to determine the proper directory. [David] * Added the DEF_MEDIA_TYPE directive. Bricolage will use the value in this directive to assign a Media Type to all file resources if they Bricolage can't figure it out from their file extentions. This fixes a bug where Bricolage would choke if it couldn't figure out the MediaType itself. [David] Enjoy! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: testing server response time
After I set up my app (webtool.cgi) and created the single script version (bigtool.cgi), I ran this script on my machine and it showed that the single file was about 10-15% faster than the multiple modules. No offense, but your script must not have been doing much in this test. The difference between putting everything in one script vs. using modules is just the time it takes to open and read the files. It's a tiny difference in most cases. Are you sure you were compiling all of the same code in both cases? My first question is, is the above script a valid test of CGI response time? It's not useless, but LWP isn't the fastest and it's a lot easier to just use ab, or one of the other tools suggested in the guide. So, for example, should the results reflect any improvements with mod_perl enabled? Yes. Because what I found is that the response time differed less than 5% between mod_perl-enabled and mod_perl disabled configurations. There could be a problem in your config. How about posting the part you changed to enable mod_perl? From other postings, it seems like Windows mod_perl works great, and I should see a significant speed-up. Not as much as on unix, but definitely a speed-up. - Perrin
Re: testing server response time
Perrin, Thanks for the response, --- Perrin Harkins [EMAIL PROTECTED] wrote: No offense, but your script must not have been doing much in this test. The difference between putting everything in one script vs. using modules is just the time it takes to open and read the files. It's a tiny difference in most cases. I was also thinking it would only make a small difference, but I see many perl/CGI scripts that boast 'all this functionality in a single script' as if multiple module was some sort of huge performance hit. My app has 13 separate modules, so I tried to test it. I'm sure both version had the same code, because they both worked fine. It's about 4000 lines of perl code (with CGI_Lite built in). So I was surprised it made such a big difference, as well. You can see a demo of the app at http://chicodigital.com/demo.html There could be a problem in your config. How about posting the part you changed to enable mod_perl? This is the lines in C:\indigoperl\conf\httpd.conf. I either commented out and restarted the server to disable, or uncommented, stopped apache and restarted to enable: # BEGIN MOD_PERL CONFIG #LoadModule perl_module modules/mod_perl.so #ScriptAlias /perl-bin/ c:/IndigoPerl//perl-bin/ #PerlSendHeader On #SetHandler perl-script #Options ExecCGI #/Location # END MOD_PERL CONFIG The application under test runs fine in either case. thanks again, -alan __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
Re: testing server response time
I was also thinking it would only make a small difference, but I see many perl/CGI scripts that boast 'all this functionality in a single script' They probably don't know any better, but to me that translates to giant bloated unorganized mess of a script. # BEGIN MOD_PERL CONFIG #LoadModule perl_module modules/mod_perl.so #ScriptAlias /perl-bin/ c:/IndigoPerl//perl-bin/ #PerlSendHeader On #SetHandler perl-script #Options ExecCGI #/Location # END MOD_PERL CONFIG That won't do it. Check the docs for Apache::Registry. That ScriptAlias should be removed for mod_perl. You want something more like this: Alias /perl-bin/ c:/IndigoPerl//perl-bin/ PerlModule Apache::Registry Location /perl-bin SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Location Not sure if you need PerlSendHeader or not. It depends on your code. - Perrin
Re: testing server response time
Perrin, You want something more like this: Alias /perl-bin/ c:/IndigoPerl//perl-bin/ PerlModule Apache::Registry Location /perl-bin SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI /Location Yup, this gets it working (It does need the line LoadModule perl_module modules/mod_perl.so). The response time for the one-liner script is reduced by a 10x factor after the first request, according to my test script. The conf snippet I gave you was somehow corrupted when I copied it, but just to make sure, I reinstalled indigoperl from scratch, and the conf file from the original install does not work; PerlModule Apache::Registry is not declared, and it uses ScriptAlias /perl-bin/ instead of Alias /perl-bin/ and I verified that both of these lines cause problems. IndigoStar says that the server comes with mod_perl enabled by default, and so I just assumed those lines were correct. You saved me a lot of time, thanks! I'll email IndigoStar this info... -alan __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
just launched, powered by mod_perl
Page-a-Day® Online Calendars: http://www.pageaday.com/ The online version of Workman Publishing's famous boxed Page-a-Day desk calendars is now powered by Apache/1.3.20 (Unix) mod_perl/1.25, MySQL 3.23 and IBM Linux servers. Each printed calendar (available in thousands of bookstores and gift shops nationwide) contains a unique Page-A-Day Online I.D. code in the back which can be used to sign up for a free Online Calendar from www.pageaday.com. The new 2002 online calendars, replacing the 2001 downloadable (win32 application) calendars, went online January 1st, and since then (8 days) over 10,000 users have signed up and redeemed their I.D. codes to use online calendar. The response was so overwhelming that current bandwidth limitations are red-lined and we're now waiting on a telco upgrade to the dedicated T1 circuit. David Kaufman [EMAIL PROTECTED] Vanguard Media Corp (212) 242-5317 Ext 125
cvs commit: modperl-2.0/t/protocol/TestProtocol eliza.pm
dougm 02/01/10 09:26:20 Modified:t/protocol/TestProtocol eliza.pm Log: chomp the string before testing value Revision ChangesPath 1.2 +1 -0 modperl-2.0/t/protocol/TestProtocol/eliza.pm Index: eliza.pm === RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/eliza.pm,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- eliza.pm 6 Sep 2001 02:45:13 - 1.1 +++ eliza.pm 10 Jan 2002 17:26:20 - 1.2 @@ -19,6 +19,7 @@ my $rlen = BUFF_LEN; $socket-recv($buff, $rlen); last if $rlen = 0; +chomp $buff; $last++ if $buff eq 'good bye'; $buff = $mybot-transform( $buff ) . \n; $socket-send($buff, length $buff);
cvs commit: modperl-site win32_binaries.html win32_binaries.pod win32_compile.html win32_compile.pod win32_multithread.html win32_multithread.pod
stas02/01/10 14:30:37 Modified:.win32_binaries.html win32_binaries.pod win32_compile.html win32_compile.pod win32_multithread.html win32_multithread.pod Log: AddModule mod_perl.c comments Submitted by: Randy Kobes [EMAIL PROTECTED] Revision ChangesPath 1.2 +21 -2 modperl-site/win32_binaries.html Index: win32_binaries.html === RCS file: /home/cvs/modperl-site/win32_binaries.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- win32_binaries.html 21 Dec 2001 07:44:43 - 1.1 +++ win32_binaries.html 10 Jan 2002 22:30:37 - 1.2 @@ -44,13 +44,23 @@ PRE A HREF=http://www.indigostar.com/;http://www.indigostar.com//A/PRE PRE - A HREF=ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe;ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe/A/PRE + A HREF=ftp://theoryx5.uwinnipeg.ca/pub/other/; +ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-x.x.exe/A/PRE PAs well as including a number of non-core modules, both of these packages contain mod_perl. See the documentation on the web sites and that included with the packages for installation instructions. Both of these also include an ActiveState-compatible CODEppm/CODE (Perl Package Manager) utility for adding and upgrading modules./P P +For the adventuresome who want a taste of things to come, a +mod_perl-2.0/Apache-2.0 binary distribution based on cvs +sources is available from +A HREF=ftp://theoryx5.uwinnipeg.ca/pub/other/Apache2.tar.gz; +ftp://theoryx5.uwinnipeg.ca/pub/other/Apache2.tar.gz/A. +See the accompanying EMApache2.readme/EM file in this directory for more +details. Be aware though that, being a pre-release version, +bugs are most likely present./P +P HR H1A NAME=ppm packagesPPM Packages/A/H1 PFor users of ActivePerl, available from/P @@ -107,7 +117,16 @@ PRE LoadModule perl_module modules/mod_perl.so/PRE PBe sure that the path to your Perl binary (eg, EMC:\Perl\bin/EM) is in -your CODEPATH/CODE environment variable./P +your CODEPATH/CODE environment variable. If you have a +CODEClearModuleList/CODE +directive enabled in EMhttpd.conf/EM, you may also need to add +PRE + AddModule mod_perl.c/PRE +PSee the descriptions of the CODEClearModuleList/CODE and +CODEAddModule/CODE +directives in the Apache documents for more details, especially +concerning the relative order of these and the +CODELoadModule/CODE directive./P P H2A NAME=registry scriptsRegistry scripts/A/H2 PUsing CODEApache::Registry/CODE to speed up cgi scripts may be done as 1.2 +16 -1 modperl-site/win32_binaries.pod Index: win32_binaries.pod === RCS file: /home/cvs/modperl-site/win32_binaries.pod,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- win32_binaries.pod21 Dec 2001 07:44:43 - 1.1 +++ win32_binaries.pod10 Jan 2002 22:30:37 - 1.2 @@ -23,6 +23,14 @@ these also include an ActiveState-compatible Cppm (Perl Package Manager) utility for adding and upgrading modules. +For the adventuresome who want a taste of things to come, a +mod_perl-2.0/Apache-2.0 binary distribution based on cvs +sources is available from +ftp://theoryx5.uwinnipeg.ca/pub/other/Apache2.tar.gz. +See the accompanying FApache2.readme file in this directory for more +details. Be aware though that, being a pre-release version, +bugs are most likely present. + =head1 PPM Packages For users of ActivePerl, available from @@ -87,7 +95,14 @@ LoadModule perl_module modules/mod_perl.so Be sure that the path to your Perl binary (eg, FC:\Perl\bin) is in -your CPATH environment variable. +your CPATH environment variable. If you have a CClearModuleList +directive enabled in Fhttpd.conf, you may also need to add + + AddModule mod_perl.c + +See the descriptions of the CClearModuleList and CAddModule +directives in the Apache documents for more details, especially +concerning the relative order of these and the CLoadModule directive. =head2 Registry scripts 1.2 +10 -1 modperl-site/win32_compile.html Index: win32_compile.html === RCS file: /home/cvs/modperl-site/win32_compile.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- win32_compile.html21 Dec 2001 07:44:43 - 1.1 +++ win32_compile.html10 Jan 2002 22:30:37 - 1.2 @@ -162,7 +162,16 @@ PRE LoadModule perl_module modules/mod_perl.so/PRE PBe sure that the path to your Perl binary (eg, EMC:\Perl\bin/EM) -is in
