Forking w/ mod_perl 2
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
Re: Forking w/ mod_perl 2
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 + threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
signature.asc
Description: This is a digitally signed message part
RE: Forking w/ mod_perl 2
Hi Richard,
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of
code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 +
threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
Thanks for you reply. The report code is in another perl program that I'm
trying to execute. The code I included below was from the v1 docs:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
Here is the code I ended up with:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This seems to work and no zombies are floating around. But I've not been
able to restart Apache while the forked program is running yet to see if
it's killed.
More comments or ideas welcome.
Thanks,
Cameron
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15
minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain
those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
Re: Advice sought for learning mod_perl (2 or 1)
Robert Lee wrote: Ged Haywood wrote: Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? No no. Apache::Request 2 port is in works and it'll be available RSN thanks to Joe Schaefer and Randy Kobes who do an extraordinary job. Though it'll be released sooner if more people help with testing and polishing it. For more information see: http://httpd.apache.org/apreq/ [...] Stas, if you have the email of Joe and Randy, please email me; I'll see if I am of any use to them. You can find the address of the apreq-dev list at: http://httpd.apache.org/apreq/. Once you are subscribed to it, you will know where exactly you can help. Thanks. __ 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: Advice sought for learning mod_perl (2 or 1)
Ged Haywood wrote: Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? No no. Apache::Request 2 port is in works and it'll be available RSN thanks to Joe Schaefer and Randy Kobes who do an extraordinary job. Though it'll be released sooner if more people help with testing and polishing it. For more information see: http://httpd.apache.org/apreq/ Thanks for the responses; they were very helpful. BTW: No, there are no commercial pressures involved in this project, but just doing a possible/likely career transition from the embedded-telecom implosion to something more of the future. However, time (as always) is always of the essence, and I'll need to balance my choices available. It's funny. I thought that Java would be a predominant player in the web world, but it looks like perl et al are the predominant players. That's ok as I'm was never a huge fan of Java anyhow ;p. Enough of my rant. Thanks again. Stas, if you have the email of Joe and Randy, please email me; I'll see if I am of any use to them. Robert _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Advice sought for learning mod_perl (2 or 1)
Hi everyone, I am new to Apache/mod_perl and everything else. I bought a fairly good book on Apache/mysql/mod_perl. Unfortunately, it is based on the Apache 1 server and mod_perl1. In doing so, it is using the Apache::Request module which has not been ported to mod_perl2 yet. Several questions come to mind: Q1: Is there a similar module to Apache::Request? Similar to syntax that is. Q2: Any real benefits to working on the latest and greatest? Or should I go to the older versions? Yes, I realize that for Q2, I may want to simply go with the more stable versions of the Apache server and mod_perl as I am just learning, but I would like to hear some opinions. Thanks. Robert FYI: OS - RH v8.0 Apache - v2.45 mod_perl - 1.99.09 perl - v5.8 _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
Re: Advice sought for learning mod_perl (2 or 1)
Hello there, On Thu, 24 Jul 2003, Robert Lee wrote: I am new to Apache/mod_perl and everything else. We're all still learning... I bought a fairly good book on Apache/mysql/mod_perl. There are others, see the mod_perl web site: http://perl.apache.org Unfortunately, it is based on the Apache 1 server and mod_perl1. That's not too bad, there are lots of similarities. Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? Q2: Any real benefits to working on the latest and greatest? Or should I go to the older versions? Depends what you want to do... :) If you are interested in learning about it and you don't have a project that you have to put on a live Webserver in a couple of months' time, I'd say stay with mp2 and watch it evolve. Maybe get involved in some of the development. I wouldn't consider mp2 for production use yet because of that evolution process if for no other reason, but if you don't have the commercial pressures then it doesn't matter so much and there's no point your spending a lot of time learning about something if it's going to be more-or-less history by the time you need to use it seriously. I realize that for Q2, I may want to simply go with the more stable versions of the Apache server and mod_perl as I am just learning For your education it's probably worth your while learning how to get the latest CVS versions, at least of mod_perl. The latest versions of Apache2 and mod_perl2 will be quite stable enough for you to use to learn about them. Now your browsers on the other hand... 73, Ged.
Re: Advice sought for learning mod_perl (2 or 1)
Ged Haywood wrote: Q1: Is there a similar module to Apache::Request? Depends what you want to do, but not really. Care to try porting it? No no. Apache::Request 2 port is in works and it'll be available RSN thanks to Joe Schaefer and Randy Kobes who do an extraordinary job. Though it'll be released sooner if more people help with testing and polishing it. For more information see: http://httpd.apache.org/apreq/ __ 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::Registry in mod_perl 2
--- Stas Bekman [EMAIL PROTECTED] wrote: ColinB wrote: So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? simply copy it into one of the dirs in your @INC. You will also need to load Apache::compat for it to work. Thanks. I've untarred mod_perl 1.0 and searched for any Registry* filnames: ./lib/Apache/RegistryBB.pm ./lib/Apache/RegistryNG.pm ./lib/Apache/Registry.pm ./lib/Apache/RegistryLoader.pm Do I need to copy ALL of these files (and maybe others?) or just the ./lib/Apache/Registry.pm file? __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Apache::Registry in mod_perl 2
[please don't take the threads off the list] ColinB wrote: --- Stas Bekman [EMAIL PROTECTED] wrote: ColinB wrote: So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? simply copy it into one of the dirs in your @INC. You will also need to load Apache::compat for it to work. Thanks. I've untarred mod_perl 1.0 and searched for any Registry* filnames: ./lib/Apache/RegistryBB.pm ./lib/Apache/RegistryNG.pm ./lib/Apache/Registry.pm ./lib/Apache/RegistryLoader.pm Do I need to copy ALL of these files (and maybe others?) or just the ./lib/Apache/Registry.pm file? If you are going to use only Apache::Registry you only need to copy lib/Apache/Registry.pm __ 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
Apache::Registry in mod_perl 2
This page: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends says that mod_perl 2's ModPerl::Registry does not chdir() into the script's directory, wheras mod_perl 1's Apache::Registry DOES chdir(). It also says that this will eventually be fixed by the time mod_perl 2 is released, and in the meantime you can use the Apache::Registry (which is part of mod_perl 1) in mod_perl 2. As I will be trying to get some old scripts working in mod_perl 2, it seems prudent to use Apache::Registry. So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? Colin __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Apache::Registry in mod_perl 2
ColinB wrote: This page: http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends says that mod_perl 2's ModPerl::Registry does not chdir() into the script's directory, wheras mod_perl 1's Apache::Registry DOES chdir(). It also says that this will eventually be fixed by the time mod_perl 2 is released, and in the meantime you can use the Apache::Registry (which is part of mod_perl 1) in mod_perl 2. As I will be trying to get some old scripts working in mod_perl 2, it seems prudent to use Apache::Registry. You have omitted this sentence: However you will have problems if you are using anything but the preforked MPM, the main reason why ModPerl::Registry doesn't chdir(). So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? simply copy it into one of the dirs in your @INC. You will also need to load Apache::compat for it to work. Alternatively you can subclass ModPerl::Registry's chdir_file function to perform chdir, like Apache::Registry does. __ 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::Registry in mod_perl 2
On Tue, 2003-07-15 at 08:44, ColinB wrote: So how can I go about installing just Apache::Registry from the mod_perl 1 tar file without having to install ALL of mod_perl 1 ? Just copy the Apache/Registry.pm file into the same directory that all your other Apache:: modules are in. - Perrin
mod_perl 2 and file upload how-to
Hello, I need help in file uploading with mod_perl 2. Apache::Request is not compatible with mod_perl 2, and I want to know how can I upload file widthout using CGI.pm Please send me an example if possible. Thanks, Alejandro.
Re: mod_perl 2 and file upload how-to
Alejandro Galue wrote: Hello, I need help in file uploading with mod_perl 2. Apache::Request is not compatible with mod_perl 2, and I want to know how can I upload file widthout using CGI.pm Please send me an example if possible. Simply copy the relevant code from CGI.pm. Alternatively if you have some time help Joe to finish the porting of Apache::Request, which is getting there. Join the apreq-dev list: http://httpd.apache.org/apreq/, and offer your help. __ 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: Problem with a custom response handler and mod_perl 2
Alejandro Galue wrote: Hello, I'm using redhat 8.0 (mod_perl-1.99_05-3, httpd-2.0.40-11.3). I created a custom handler for http responses, and I get this error in httpd log: [Tue Jun 03 07:42:53 2003] [error] [client 127.0.0.1] Can't locate object method header_in via package Apache::RequestRec at /usr/lib/perl5/site_perl/sgi/apache/cgi/init.pm line 27.!, referer: http://localhost:8080/main.html BUT, I have other redhat 8.0 implementation with the same handler and does not have this problem. Any suggestions RTFM, http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_header_in_ __ 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
Problem with a custom response handler and mod_perl 2
Hello, I'm using redhat 8.0 (mod_perl-1.99_05-3, httpd-2.0.40-11.3). I created a custom handler for http responses, and I get this error in httpd log: [Tue Jun 03 07:42:53 2003] [error] [client 127.0.0.1] Can't locate object method header_in via package Apache::RequestRec at /usr/lib/perl5/site_perl/sgi/apache/cgi/init.pm line 27.!, referer: http://localhost:8080/main.html BUT, I have other redhat 8.0 implementation with the same handler and does not have this problem. Any suggestions Thanks... Alejandro
Mod_Perl 2?
Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13.
Re: Mod_Perl 2?
Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. http://perl.apache.org/docs/2.0/user/porting/compat.html#Code_Porting http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups __ 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: Mod_Perl 2?
Here is what the Command_Line_Lookups tells me: to use method 'server_root_relative' add: use Apache::ServerUtil (); here is what my .pl file looks like before I make any modifications: :: CODE :: use Apache2 (); use ModPerl::Util (); use Apache::RequestRec (); use Apache::RequestIO (); use Apache::RequestUtil (); use Apache::Server (); use Apache::ServerUtil (); use Apache::Connection (); use Apache::Log (); use Apache::Const -compile = ':common'; use APR::Const -compile = ':common'; use APR::Table (); use Apache::compat (); use ModPerl::Registry (); use CGI (); use XML::LibXML(); use XML::LibXSLT(); 1; :: END CODE :: that is it... still compiles with an error =( -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 10:10 PM To: Ryan Farrington Cc: [EMAIL PROTECTED] Subject: Re: Mod_Perl 2? Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Per l/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. http://perl.apache.org/docs/2.0/user/porting/compat.html#Code_Porting http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Li ne_Lookups __ 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: Mod_Perl 2?
Ryan Farrington wrote: Here is what the Command_Line_Lookups tells me: to use method 'server_root_relative' add: use Apache::ServerUtil (); [...] that is it... still compiles with an error =( right, the API change. Here is the correct URL: http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_server_root_relative_ Can't locate object method server_root_relative via package Apache __ 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: Mod_Perl 2?
On Thu, 29 May 2003, Ryan Farrington wrote: Ok here is the error I get when using the all-in-one install for mod_perl 2.0 Can't locate object method server_root_relative via package Apache at e:/Perl/site/lib/Apache/compat.pm line 69. Compilation failed in require at startup.pl line 13. BEGIN failed--compilation aborted at startup.pl line 13. Are you invoking startup.pl from the command line: C:\Apache2\conf perl startup.pl If so, this won't work - it needs to be loaded within the Apache environnment, upon starting Apache. Does Apache start OK with this startup.pl? -- best regards, randy
Re: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
At 18:35 04.04.2003, Randy Kobes wrote: If this is with ActivePerl 8xx, though, then it may be that there's an incompatibility between modules compiled against Apache 2.0.44 (which the mod_perl ppm package on our site was compiled against) and Apache 2.0.45. The Apache group says that, starting with 2.0.42, they're working at maintaining configuration and module interface compatibility, so in principle upgrading from 2.0.44 to 2.0.45 shouldn't be a problem. But with a combination of Win32 and the relative complexity of mod_perl 2, this compatibility may not have survived I've tried compiling the current cvs mod_perl 2 sources against Apache 2.0.45, but have run into a problem (unrelated to the 2.0.45 upgrade) that hasn't yet been resolved. Given the security fixes for Win32 present in 2.0.45, if you feel uneasy about reverting to 2.0.44, I could make available a mod_perl 2 package based on not-so-current cvs sources compiled against 2.0.45 until the problem in the current cvs version is fixed. Just had another thought... maybe you should indeed recompile mod_perl-2 with the older CVS sources, so I can try it out on Apache 2.0.45, and we can be 100% sure that this is the problem... Maybe the problem really is that the old binaries aren't compatible with the new Apache, but at the moment we just don't know. Trying it out would help. Of course it's not necessary if it means too much effort... it would be interesting though to see if the recompile really does solve the problem. Thank You, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org
RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
Title: RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes Sebastian, Sooo, it IS possible to get this running on W2000. thanks! Now the big question: what is different between your system and ours...? Do you remember what happened during install, what non-standard files [installed after base W2000] you have on your machine, or any other things that may explain the difference. We can get in touch off-list and exchange more details -Original Message- From: Sebastian Breier [mailto:[EMAIL PROTECTED]] Sent: Friday, April 04, 2003 15:58 To: [EMAIL PROTECTED] Subject: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes Hi. I just upgraded Apache to 2.0.45 (from 2.0.44), and now most of my perl-generated sites crash. They worked perfectly before. Server is Apache 2.0.45 on W2000 + mod_perl-2 1.99_09-dev, as said in the subject. I just checked again with 2.0.44, everything works (nothing changed except Apache). One script still works with 2.0.45, but it has only a few subs that don't do anything. Logs always show some error message like these: [Fri Apr 04 15:49:29 2003] [notice] Parent: child process exited with status 1073807364 -- Restarting. or [Fri Apr 04 15:46:53 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. Any ideas? Do I need a recompile of mod_perl-2? (I hope somebody makes one, I can't) Thank You, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org Sorry I cannot help with your Apache 2.0.45 problem, we're not there yet... -- Thanks, Matthijs Melchior.
RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
At 17:38 04.04.2003, Melchior, Matthijs wrote: Sebastian, Sooo, it IS possible to get this running on W2000. thanks! Of course it's possible... :-P I've been running it for a year now I think... though my main Apache box is WinNT 4 SP6a. Now the big question: what is different between your system and ours...? Do you remember what happened during install, what non-standard files [installed after base W2000] you have on your machine, or any other things that may explain the difference. Nothing special... Win2k Pro SP2, some patches for security... What exactly is your problem with the installation? Mine went through without complaining, and the Apache worked after that. mod_perl-2 is installed over ActivePerl 5.8's PPM shell. No problems anywhere. Just now with 2.0.45. :-) We can get in touch off-list and exchange more details Sure... maybe this annoys the other list-readers... but maybe it's also helpful for others! Bye, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org
RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
Title: RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes Sebastian, -Original Message- From: Sebastian Breier [mailto:[EMAIL PROTECTED]] Sent: Friday, April 04, 2003 17:51 At 17:38 04.04.2003, Melchior, Matthijs wrote: Sebastian, Sooo, it IS possible to get this running on W2000. thanks! Of course it's possible... :-P I've been running it for a year now I think... though my main Apache box is WinNT 4 SP6a. Now the big question: what is different between your system and ours...? Do you remember what happened during install, what non-standard files [installed after base W2000] you have on your machine, or any other things that may explain the difference. Nothing special... Win2k Pro SP2, some patches for security... What exactly is your problem with the installation? Mine went through without complaining, and the Apache worked after that. Well, the problem does not occur at installation time, that was without problem. It happens when Apache wants to load mod_perl.so, then it dies with error The specified procedure could not be found. Note, it talks about 'prodedure', not 'module'. To me this means that the loading of the module failed because the dynamic linker [the unix name, dont know the windows term...] cannot resolve a symbol in mod_perl.so or one of the referenced libraries. Unfortunately, windows does not tell me the name of the problematic symbol so I have no idea where to look! mod_perl-2 is installed over ActivePerl 5.8's PPM shell. No problems anywhere. Just now with 2.0.45. :-) We can get in touch off-list and exchange more details Sure... maybe this annoys the other list-readers... but maybe it's also helpful for others! I was thinking about boring details like versions of DLL's in \winnt\system32 and places like that If we can solve this without resorting to that comparation, even better. Bye, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org -- Thanks, Matthijs Melchior. [can't access this mailbox during the weekend...]
Re: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
On Fri, 4 Apr 2003, Sebastian Breier wrote: Hi. I just upgraded Apache to 2.0.45 (from 2.0.44), and now most of my perl-generated sites crash. They worked perfectly before. Server is Apache 2.0.45 on W2000 + mod_perl-2 1.99_09-dev, as said in the subject. I just checked again with 2.0.44, everything works (nothing changed except Apache). One script still works with 2.0.45, but it has only a few subs that don't do anything. Logs always show some error message like these: [Fri Apr 04 15:49:29 2003] [notice] Parent: child process exited with status 1073807364 -- Restarting. or [Fri Apr 04 15:46:53 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. Any ideas? Do I need a recompile of mod_perl-2? (I hope somebody makes one, I can't) From a later message I take it this is with ActivePerl 8xx (perl-5.8.0)? If not, and you're using ActivePerl 6xx, then it may be that you're running into a problem that others have also seen with ActivePerl 6xx and mod_perl 2 on Win32, for which an upgrade to 8xx would most likely help. If this is with ActivePerl 8xx, though, then it may be that there's an incompatibility between modules compiled against Apache 2.0.44 (which the mod_perl ppm package on our site was compiled against) and Apache 2.0.45. The Apache group says that, starting with 2.0.42, they're working at maintaining configuration and module interface compatibility, so in principle upgrading from 2.0.44 to 2.0.45 shouldn't be a problem. But with a combination of Win32 and the relative complexity of mod_perl 2, this compatibility may not have survived I've tried compiling the current cvs mod_perl 2 sources against Apache 2.0.45, but have run into a problem (unrelated to the 2.0.45 upgrade) that hasn't yet been resolved. Given the security fixes for Win32 present in 2.0.45, if you feel uneasy about reverting to 2.0.44, I could make available a mod_perl 2 package based on not-so-current cvs sources compiled against 2.0.45 until the problem in the current cvs version is fixed. -- best regards, randy kobes
Re: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
At 18:35 04.04.2003, Randy Kobes wrote: If this is with ActivePerl 8xx, though, then it may be that there's an incompatibility between modules compiled against Apache 2.0.44 (which the mod_perl ppm package on our site was compiled against) and Apache 2.0.45. The Apache group says that, starting with 2.0.42, they're working at maintaining configuration and module interface compatibility, so in principle upgrading from 2.0.44 to 2.0.45 shouldn't be a problem. But with a combination of Win32 and the relative complexity of mod_perl 2, this compatibility may not have survived I've tried compiling the current cvs mod_perl 2 sources against Apache 2.0.45, but have run into a problem (unrelated to the 2.0.45 upgrade) that hasn't yet been resolved. Given the security fixes for Win32 present in 2.0.45, if you feel uneasy about reverting to 2.0.44, I could make available a mod_perl 2 package based on not-so-current cvs sources compiled against 2.0.45 until the problem in the current cvs version is fixed. Yes, It's ActivePerl 5.8.0.805. About the mod_perl-2 recompile: It's not necessary for me. Thank You for the offer, but this machine is a private one anyway, and I can stay on 2.0.44 until the fixed CVS is there and compiled. I guess You'll drop a message here when that happens? :-) Thank You, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org
RE: [mp2.0] W2000, Apache 2.0.45, mod_perl-2 1.99_09-dev crashes
At 18:14 04.04.2003, Melchior, Matthijs wrote: Well, the problem does not occur at installation time, that was without problem. It happens when Apache wants to load mod_perl.so, then it dies with error The specified procedure could not be found. Note, it talks about 'prodedure', not 'module'. To me this means that the loading of the module failed because the dynamic linker [the unix name, dont know the windows term...] cannot resolve a symbol in mod_perl.so or one of the referenced libraries. Unfortunately, windows does not tell me the name of the problematic symbol so I have no idea where to look! How exactly do you install Apache and mod_perl-2? My install/upgrade process is this: - Install Apache via MSI file - Open ActivePerl's PPM - Add mod_perl-2 PPM repository ( http://theoryx5.uwinnipeg.ca/cgi-bin/ppmserver?urn:/PPMServer58 ActivePerl 5.8 only) - install mod_perl from that repository, the PPM package installation will place the mod_perl.so file in the correct Apache directory. My first guess is that you are using a wrong version of mod_perl... maybe you are trying to use mod_perl-1 with Apache 2? Or maybe just an outdated mod_perl-2 with Apache 2? The way I described above works perfectly for 2.0.43 and 2.0.44... Another thing might be the config file. My current lines for mod_perl-2 in httpd.conf: Loadmodule perl_module modules/mod_perl.so (Then some handlers for my directories so .pl files get executed with mod_perl, but these only matter when you can start Apache/mod_perl at all) PerlSwitches -Mblib=C:\Apache2 PerlRequire C:/Apache2/conf/startup.pl PerlModule Apache::Reload PerlInitHandler Apache::Reload Maybe some of the rather important settings for mod_perl-2 are wrong in your config... I was thinking about boring details like versions of DLL's in \winnt\system32 and places like that If we can solve this without resorting to that comparation, even better. No idea about those, but Apache is probably away far enough from the OS to not be dependent on Win32 System DLLs... Bye, Sebastian. -- If You're European, do something for YOUR civil rights: http://www.stop1984.com Stop software patents in the EU! http://swpat.ffii.org
Re: problems installing mod_perl 2
Carlos Villegas wrote: Hi, First some basic info: -Apache 2.0.44 -Solaris 9 sparc -perl 5.8.0 -mod_perl-1.99_08 (from mod_perl-2.0-current.tar.gz) -complete newbie to mod_perl I had some problems to compile mod_perl: make test would fail, after reading the mailing list archives, I found a few things related to my problem, so I added a few lines to: t/hooks/TestHooks/init.pm and t/hooks/TestHooks/trans.pm (I can post a diff if it's of interest) Certainly. But please follow the bug reporting guidelines: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems This fixed some problems, but not all of them. I decided to ignore further failures of make test, and did a make install, it failed (?), however I did get a mod_perl.so under $apacheroot/modules, so I added the LoadModule line to apache, and restarted it. It seems to work, however I can't load my module (using PerlHandler mymodule), because it can't find Apache::Constants (which I use in my module). I have tried to install this (Apache::Constants) by using the shell of CPAN, but it refuses to install for apache2, I saw some references to Apache2 somewhere in the archives, but couldn't find it either (using CPAN shell). Does make install add some more stuff besides mod_perl.so? My perl is in a read only path, so this might be the problem, but I'm not sure... Which are the specific dependencies for mod_perl 2? It's all very well documented. Please spend some time at: http://perl.apache.org/docs/2.0/index.html in particular: http://perl.apache.org/docs/2.0/user/compat/compat.html How stable is mod_perl 2? Getting better every day. There are still problems here and there, but they get resolved when reported. See the todo directory and the STATUS file in the mod_perl source for things that are still missing. __ 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
file upload under mod_perl 2 wihout CGI.pm
Hello.How can I get file upload from form using mod_perl 2 without CGI.pm?thx
Re: file upload under mod_perl 2 wihout CGI.pm
On Tue, 4 Mar 2003, Egor Korablev wrote:
Hello.
How can I get file upload from form using mod_perl 2 without CGI.pm?
thx
You can't. At least not in an easy way, which I guess is what you want.
Apache::Request is not ported to mod_perl 2 yet. Time to fall back in love
with CGI.pm, just like when you were a young man and the web was even
younger :)
- nick
--
Nick Tonkin {|8^)
RE: mod_perl 2 apache::session and or die
Thanks Perrin, I've been trying to use Apache::DB to track down the problem, but I'm not having a lot of luck. I think it is in the locking as if I let things hang long enough and then shut down Apache, I get a error of: Can't call method disconnect on an undefined value at /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Lock/MySQL.pm line 89 during global destruction. Which is Apache::Session::Lock:MySQL I'm still no closer as to figuring out why though. -Chris -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 11:55 AM To: Chris Faust Cc: Modperl Subject: Re: mod_perl 2 apache::session and or die Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. - Perrin
mod_perl 2 apache::session and or die
I'm having a problem since installing Apache::Session All works well except when there is any kind of problem in the script where the condition will die.. For example: $db-execute() or die... open yadda or die.. $db-prepare() or die... etc. When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged - if you close all windows and try again then the same thing just happens, it goes forever and nothing happens or is logged. It doesn't seem to matter where the die is, if I'm using another module (for example) HTML::Template and it dies on bad params because I didn't define something some temple var then that is it.. I can't get to that script again until I reload Apache. This only happens when I'm using Apache::Session::MySQL and I'm not doing anything strange with it, I grab the cookie if its there and authenticate them. There is nothing I'm doing in the session that relates to the errors so I don't understand why everything just dies as it does. This happens on my RH7.3/1.3 install and on my RH8/2.0 install. One other thing I should mention, when this happens it only kills the script in that specific location that is defined in the httpd.conf, in otherword something running in /cgi-bin1/ has died and crashed, I can't get to it or do anything with it - during this time everything running in /cgi-bin2/ is running along just fine without a issue (although what is in /cgi-bin2/ isn't using Apache::Session but it is using the same mySql DB). Any ideas? Thanks -Chris
Re: mod_perl 2 apache::session and or die
Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. - Perrin
Re: mod_perl 2 apache::session and or die
Perrin Harkins wrote: Chris Faust wrote: All works well except when there is any kind of problem in the script where the condition will die.. [...] When this happens everything to do with that script is unresponsive - I know that is a little vague but that is the best way I can describe it. What happens is the error comes up (standard server error) and that is the last thing that is logged, if you try to go back and refresh the hourglass will go for hours and nothing happens and nothing is ever logged It sounds like a locking problem to me. I'm guessing that mod_perl 2 is not calling the right hooks when it traps a die() to trigger the DESTROY method in Apache::Session which releases all locks. You can find out exactly what's going on if you run it in the debugger (Apache::DB) or throw some debug logging into Apache::Session to find out where it gets stuck. This is the beauty of having the source code. I've noticed that there are several issues with END blocks with the current cvs, when the used perl is threaded. Could be that DESTROY misbehaves too. I've planned to investigate these issues, but didn't have a chance to yet. Hopefully someone will beat me to it. __ 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::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? [EMAIL PROTECTED] wrote: As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. A while back Andrew Ho posted his script, apr, that is similar to Apache::FakeRequest: http://marc.theaimsgroup.com/?l=apache-modperlm=98719810927157w=2 I've attached a slightly updated version called runtsp. Although it's called runtsp, it should handle Apache::Registry scripts just fine. (Tellme::Apache::TSP is our templating module a la Apache::ASP.) - Kyle runtsp Description: Binary data
RE: Apache::DBI and mod_perl 2
Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 Thanks, I didn't know that at all as I test all my modules that way and have never had a problem.. Of course most are not mod_perl specific. -Chris
Re: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? There are plans. Here is an entry from modperl-2.0/todo/api.txt: Apache::FakeRequest: since APR can be used outside of httpd, and we can alloc request_rec and similar structures, it should be possible to bootstrap an inside-httpd interface and outside-httpd interface. its not really worthwhile looking at until APR actually installs its *.so or *.a libraries somewhere apxs can find them. and, there's a bunch of util functions (e.g. URI stuff) that is supposed to move from httpd into apr-util. As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. __ 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::DBI and mod_perl 2
Chris Faust wrote: Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 [...] Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 __ 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
Apache::DBI and mod_perl 2
Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
Re: Apache::DBI and mod_perl 2
Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I can't find
anything in any of the docs and even goggle groups only had one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. Compilation failed in require at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted. [chrisf@web1 chrisf]$ I get pretty much the same thing if I try to put it into my statup.pl, scripts or httpd.conf. Thanks -Chris -Original Message- From: Dr. Helmut Zeilinger [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 9:26 AM To: Chris Faust; Modperl Subject: Re: Apache::DBI and mod_perl 2 Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
RE: Apache::DBI and mod_perl 2
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
Thanks
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:22 AM
To: Chris Faust
Cc: Modperl
Subject: Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I
can't find
anything in any of the docs and even goggle groups only had
one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with
Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Awesome!! That must be my problem..
I searched everyplace else, but totally forgot searching the list..
Sorry about that.
Thanks Again!!
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:46 AM
To: Chris Faust
Cc: Modperl
Subject: RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
Re: Has Apache::Cookie been ported to mod_perl-2 yet?
No it hasn't. Need to use CGI::Cookie for the time being. Apache::Cookie and Apache::Request I believe are both either provided by or dependent on libapreq, which is still a work in progress for apache2/mod_perl2. That's the biggest reason I'm still using Apache 1.3.x now. Wes Sheldahl Charles McElhose Jr. [EMAIL PROTECTED] on 02/10/2003 10:43:57 PM To:[EMAIL PROTECTED] cc: Subject:Has Apache::Cookie been ported to mod_perl-2 yet? Has Apache::Cookie been ported to mod_perl-2 yet? I tried to install the libapreq-1.1 module with mod_perl-2/apache 2 and am getting a can't locate Apache/MyConfig.pm ... error. Charles M. [EMAIL PROTECTED]
Re: Has Apache::Cookie been ported to mod_perl-2 yet?
[EMAIL PROTECTED] wrote: No it hasn't. Need to use CGI::Cookie for the time being. Apache::Cookie and Apache::Request I believe are both either provided by or dependent on libapreq, which is still a work in progress for apache2/mod_perl2. That's the biggest reason I'm still using Apache 1.3.x now. Incidentally, I recommend CGI::Lite. It's very small and fast, and has an API close enough to Apache::Request that you could easilly convert your code later. Handles cookies as well. - Perrin
Has Apache::Cookie been ported to mod_perl-2 yet?
Has Apache::Cookie been ported to mod_perl-2 yet? I tried to install the libapreq-1.1 module with mod_perl-2/apache 2 and am getting a can't locate Apache/MyConfig.pm ... error. Charles M. [EMAIL PROTECTED]
Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Has Apache::Cookie been ported to mod_perl-2 yet? I tried to install the libapreq-1.1 module with mod_perl-2/apache 2 and am getting a can't locate Apache/MyConfig.pm ... error. Charles M.
Re: Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Thanks, is there any word on when this may happen? Charles
Re: Fw: [Perl] how to static link mod_perl 2 into apache 2.0
I'm also running a Mason based system, but I'm sticking with mod_perl-1.0 for now. From the Mason FAQ: (http://www.masonhq.com/docs/faq/#can_i_use_mason_with_mod_perl_1_) Until some time after mod_perl 2.0 is officially released, Mason will only support mod_perl 1.x, specifically 1.22+. You may be able to use Mason with mod_perl 2.0 if you turn on mod_perl 2.0's 1.x compatibility layer by loading ``Apache::compat'' before you load Mason. Hope this helps Casey Songer [EMAIL PROTECTED] Stas Bekman wrote: Issac Goldstand wrote: Forwarding this from another list, because it's more appropriate here :-) - Original Message - *From:* Ron Gidron mailto:[EMAIL PROTECTED] *Sent:* Monday, February 10, 2003 3:48 PM *Subject:* [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command apachectl -l I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? At this point only DSO is supported by 2.0. What's wrong with using DSO? The package requires mod_perl to be statically linked, but it talks about mod_perl-1.0. I'd first check with Mason folks whether 2.0 is supported at all. __ 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: Fw: Has Apache::Cookie been ported to mod_perl-2 yet?
Charles O. McElhose Jr. wrote: Thanks, is there any word on when this may happen? Subscribe to the apreq-dev list to stay up to date with the recent developments http://httpd.apache.org/apreq/ meanwhile use CGI::Cookie if you work with mod_perl 2.0. __ 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
Fw: [Perl] how to static link mod_perl 2 into apache 2.0
Forwarding this from another list, because it's more appropriate here :-) - Original Message - From: Ron Gidron Sent: Monday, February 10, 2003 3:48 PM Subject: [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command "apachectl -l" I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? Regards, Ron Gidron.
Re: Fw: [Perl] how to static link mod_perl 2 into apache 2.0
Issac Goldstand wrote: Forwarding this from another list, because it's more appropriate here :-) - Original Message - *From:* Ron Gidron mailto:[EMAIL PROTECTED] *Sent:* Monday, February 10, 2003 3:48 PM *Subject:* [Perl] how to static link mod_perl 2 into apache 2.0 I am trying to install a Mason based system. This package requires mod_perl statically linked and not as a DSO. for this new installation I decided to test Apache 2.0 and mod_perl 2.0. I downloaded the source for both packages and I am able to configure and make / make test /make install for both without problems however when I issue the command apachectl -l I don't see any reference to mod_perl. I have tried playing with the ./configure options for apache (--enable-perl etc) but nothing seams to get me to where I need to go, this is getting quite frustrating... does anyone have any tips? have any of you installed this configuration before, do you happen to remember the order of steps you took? At this point only DSO is supported by 2.0. What's wrong with using DSO? The package requires mod_perl to be statically linked, but it talks about mod_perl-1.0. I'd first check with Mason folks whether 2.0 is supported at all. __ 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
mod_perl 2 APache 2.0 MPM
All, Starting to strike the first blows with Apache 2.0. I am now wondering about thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache config ? Thanks,
Re: mod_perl 2 APache 2.0 MPM
Sinclair, Alan (CORP, GEAccess) wrote: All, Starting to strike the first blows with Apache 2.0. I am now wondering about thread safety with mod_perl 2. Will mod_perl support a threaded MPM Apache config ? Why using the future tense, it does support the threaded mpm pretty much from the very beginning. re: thread-safety see: http://perl.apache.org/search/swish.cgi?query=thread-safesbm=SecIsubmit=search __ 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: mod_perl 2 and problems w/ ErrorDocument Directive
Sounds good. Thanks for the help. I will patch my copy. Will all MP1 functionality be migrating over to MP2? In particular the PerlHandler Apache::Status functionality. Thanks, Tom Stas Bekman wrote: Terra Info wrote: PS: I forgot to let you know if it works on MP1. I do not have that installed on any machines so if someone out there on the list could check that out and post back I would appreciate it. Everything you need is below. Here is the fix, I've messed up this part while porting. I'll commit that fix soonish + a new test. Index: lib/ModPerl/RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.23 diff -u -r1.23 RegistryCooker.pm --- lib/ModPerl/RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23 +++ lib/ModPerl/RegistryCooker.pm 24 Dec 2002 01:44:52 - @@ -157,7 +157,8 @@ # handlers shouldn't set $r-status but return it my $old_status = $self-[REQ]-status; my $rc = $self-run; -my $new_status = $self-[REQ]-status($old_status); +my $new_status = $self-[STATUS]; +$self-[REQ]-status($old_status); return ($rc != Apache::OK) ? $rc : $new_status; } __ 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 -- - Terra Novum Research [EMAIL PROTECTED] www.terranovum.com (617) 923-4132 PO Box 362 Watertown, MA 02471-0362 Patriotism means being loyal to your country all the time and to its government when it deserves it. - Mark Twain
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Terra Info wrote: Sounds good. Thanks for the help. I will patch my copy. Or just grab the latest cvs. Will all MP1 functionality be migrating over to MP2? Pretty much yes. In particular the PerlHandler Apache::Status functionality. Doug mentioned that most of its functionality works as-is. It needs some patching to work with the new registry. __ 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
[win32] perl-5.8/mod_perl-2 binary
I've placed a self-extracting archive, Perl-5.8-win32-bin.exe, at ftp://theoryx5.uwinnipeg.ca/pub/other/, which contains a Win32 binary distribution of Perl-5.8 and Apache-2.0.43, including mod_perl-1.99_08. This was built using the sources provided by ActiveState for build 804, and as such, ppm packages installed via the included ppm utility from ActiveState's 5.8 repository can be used. Two README files, a short and a long one, describe the installation. An (experimental) script is included in the Perl bin/ directory which automates some of the needed configuration (manual checking is still advised). Included in the Apache2 distribution are a sample ModPerl::Registry script, a simple mod_perl-2 handler, and sample Apache::ASP and HTML::Mason pages. An Emberl ppm package will be made when available. Please let me know of any problems you encounter in the installation, especially as related to the configuration. For questions about mod_perl-2, this list and http://perl.apache.org/ are great resources, while for Embperl, Apache::ASP, or HTML::Mason specifically, see their respective sites and lists. -- best regards, randy kobes
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Thanks for the help. Below is all the info you requested. I have also
attached the test script (code below for those attachement challenged,
et al;) and an example can be seen at
http://dev.terranovum.com/some-bad-link/. To see what it should be doing
call it directly at http://dev.terranovum.com/cgi-bin/mod_perl_list.pl.
Both links are the same script under the same mod_perl directives. The
only difference is how they are being called. If you need anything else
let me know.
Tom
Relevant httpd.conf entries:
ErrorDocument 404 /cgi-bin/mod_perl_list.pl
Location /cgi-bin
SetHandler perl-script
PerlHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
Only Log Entry:
[Sat Dec 21 17:35:46 2002] [error] [client 146.115.56.67] File does not
exist: /var/www/terradev/docs/bad-link
Output:
[snip]Additionally, a 404 Not Found error was encountered while trying
to use an ErrorDocument to handle the request.[snip]
[root@nova t]# ./TEST.PL
*** setting ulimit to allow core files
ulimit -c unlimited; ./TEST.PL
/usr/sbin/httpd -d /root/downloads/mod_perl-1.99_07/ModPerl-Registry/t
-f /root/downloads/mod_perl-1.99_07/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.40 (prefork MPM)
waiting for server to start: ...
waiting for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
basic.ok
closure...ok
redirect..ok
special_blocksok
All tests successful.
Files=4, Tests=30, 5 wallclock secs ( 1.91 cusr + 0.18 csys = 2.09 CPU)
*** server localhost.localdomain:8529 shutdown
#!/usr/bin/perl -Tw
$ENV{'PATH'} = '';
use strict;
my $retstr = Content-Type: text/html\n;
#$retstr .= sprintf(Status: %s %s\n, $status, $codes{$status}[0]);
$retstr .= sprintf(Status: %s %s\n, 404, 'Object Not Found!');
$retstr .= \n;
$retstr .= 'htmlheadtitleError 404: Object Not
Found!/title/headbody bgcolor=#FFh2Error 404: Object Not
Found!/h2pBlah, blah, blah.../p/body/html';
print($retstr);
exit;
Stas Bekman wrote:
Terra Info wrote:
I have a script that provides custom error messages that I set up
using the ErrorDocument directive (ie; ErrorDocument 400
/cgi-global/error.pl?error=400useXML=1). When run under typical
mod_cgi all works as planned and it outputs the proper stuff. When
run under mod_perl it outputs the same but then appends the default
ErrorDocument (ie; ErrorDocument 500
/error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I
have effectively two HTML docs on the output page.
The odd part of this issue is this. When it is a 404 error The stock
error doc says that Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request which makes no sense since the only log entry is File does
not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl
example below you get Additionally, a 500 Internal Server Error
error was encountered while trying to use an ErrorDocument to handle
the request. despite the fact that the custom error script did work
and output what it was supposed to and the error logs confirm that.
Looks like ModPerl::Registry is not handling correctly the return
status , hence you get the run of the default handler as well. I'll
look into it. But first, does it work properly with mod_perl 1.0?
Finally please attach the script that fails, preferrably removing all
but the very minimal code that allows to reproduce the problem. Thanks.
And if you can a test to modperl-2.0/ModPerl-Registry/t that
reproduces the problem, that would be even better. If you don't know
Apache::Test, you can learn more about it at:
http://perl.apache.org/docs/general/testing/testing.html
and looking at the existing tests. To run the registry tests you need
to cd to the ModPerl-Registry dir first and run 'make test'. If it
seems like too much work, I'll take care of adding the test. But it'd
be cool if people who encounter problems were able to submit tests
with their reports.
Thanks.
__
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
--
-
Terra Novum Research
[EMAIL PROTECTED]
www.terranovum.com
(617) 923-4132
PO Box 362
Watertown, MA 02471-0362
When a man sits with a pretty girl for an hour,
it seems like a minute. But let him sit on a hot stove
for a minute and it's longer than any hour. That's relativity.
-- Einstein, Journal of Exothermic Science and Technology (JEST, Vol. 1, No. 9; 1938)
#!/usr/bin/perl -Tw
# Relevant httpd.conf entries:
# ErrorDocument 404 /cgi-bin/mod_perl_list.pl
#Location /cgi-bin
#SetHandler
Re: mod_perl 2 and problems w/ ErrorDocument Directive
PS: I forgot to let you know if it works on MP1. I do not have that
installed on any machines so if someone out there on the list could
check that out and post back I would appreciate it. Everything you need
is below.
Tom
Terra Info wrote:
Thanks for the help. Below is all the info you requested. I have also
attached the test script (code below for those attachement challenged,
et al;) and an example can be seen at
http://dev.terranovum.com/some-bad-link/. To see what it should be
doing call it directly at
http://dev.terranovum.com/cgi-bin/mod_perl_list.pl. Both links are the
same script under the same mod_perl directives. The only difference is
how they are being called. If you need anything else let me know.
Tom
Relevant httpd.conf entries:
ErrorDocument 404 /cgi-bin/mod_perl_list.pl
Location /cgi-bin
SetHandler perl-script
PerlHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
Only Log Entry:
[Sat Dec 21 17:35:46 2002] [error] [client 146.115.56.67] File does
not exist: /var/www/terradev/docs/bad-link
Output:
[snip]Additionally, a 404 Not Found error was encountered while trying
to use an ErrorDocument to handle the request.[snip]
[root@nova t]# ./TEST.PL
*** setting ulimit to allow core files
ulimit -c unlimited; ./TEST.PL
/usr/sbin/httpd -d
/root/downloads/mod_perl-1.99_07/ModPerl-Registry/t -f
/root/downloads/mod_perl-1.99_07/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.40 (prefork MPM)
waiting for server to start: ...
waiting for server to start: ok (waited 2 secs)
server localhost.localdomain:8529 started
basic.ok
closure...ok
redirect..ok
special_blocksok
All tests successful.
Files=4, Tests=30, 5 wallclock secs ( 1.91 cusr + 0.18 csys = 2.09
CPU)
*** server localhost.localdomain:8529 shutdown
#!/usr/bin/perl -Tw
$ENV{'PATH'} = '';
use strict;
my $retstr = Content-Type: text/html\n;
#$retstr .= sprintf(Status: %s %s\n, $status, $codes{$status}[0]);
$retstr .= sprintf(Status: %s %s\n, 404, 'Object Not Found!');
$retstr .= \n;
$retstr .= 'htmlheadtitleError 404: Object Not
Found!/title/headbody bgcolor=#FFh2Error 404: Object Not
Found!/h2pBlah, blah, blah.../p/body/html';
print($retstr);
exit;
Stas Bekman wrote:
Terra Info wrote:
I have a script that provides custom error messages that I set up
using the ErrorDocument directive (ie; ErrorDocument 400
/cgi-global/error.pl?error=400useXML=1). When run under typical
mod_cgi all works as planned and it outputs the proper stuff. When
run under mod_perl it outputs the same but then appends the default
ErrorDocument (ie; ErrorDocument 500
/error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I
have effectively two HTML docs on the output page.
The odd part of this issue is this. When it is a 404 error The stock
error doc says that Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request which makes no sense since the only log entry is File does
not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl
example below you get Additionally, a 500 Internal Server Error
error was encountered while trying to use an ErrorDocument to handle
the request. despite the fact that the custom error script did work
and output what it was supposed to and the error logs confirm that.
Looks like ModPerl::Registry is not handling correctly the return
status , hence you get the run of the default handler as well. I'll
look into it. But first, does it work properly with mod_perl 1.0?
Finally please attach the script that fails, preferrably removing all
but the very minimal code that allows to reproduce the problem. Thanks.
And if you can a test to modperl-2.0/ModPerl-Registry/t that
reproduces the problem, that would be even better. If you don't know
Apache::Test, you can learn more about it at:
http://perl.apache.org/docs/general/testing/testing.html
and looking at the existing tests. To run the registry tests you need
to cd to the ModPerl-Registry dir first and run 'make test'. If it
seems like too much work, I'll take care of adding the test. But it'd
be cool if people who encounter problems were able to submit tests
with their reports.
Thanks.
__
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
#!/usr/bin/perl -Tw
# Relevant httpd.conf entries:
# ErrorDocument 404 /cgi-bin/mod_perl_list.pl
#Location /cgi-bin
#SetHandler perl-script
#PerlHandler ModPerl::Registry
#PerlOptions +ParseHeaders
#Options
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Terra Info wrote: PS: I forgot to let you know if it works on MP1. I do not have that installed on any machines so if someone out there on the list could check that out and post back I would appreciate it. Everything you need is below. Here is the fix, I've messed up this part while porting. I'll commit that fix soonish + a new test. Index: lib/ModPerl/RegistryCooker.pm === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm,v retrieving revision 1.23 diff -u -r1.23 RegistryCooker.pm --- lib/ModPerl/RegistryCooker.pm 16 Aug 2002 09:01:17 - 1.23 +++ lib/ModPerl/RegistryCooker.pm 24 Dec 2002 01:44:52 - @@ -157,7 +157,8 @@ # handlers shouldn't set $r-status but return it my $old_status = $self-[REQ]-status; my $rc = $self-run; -my $new_status = $self-[REQ]-status($old_status); +my $new_status = $self-[STATUS]; +$self-[REQ]-status($old_status); return ($rc != Apache::OK) ? $rc : $new_status; } __ 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
mod_perl 2 and problems w/ ErrorDocument Directive
I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request which makes no sense since the only log entry is File does not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl example below you get Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. The setup is plain vanilla on RH 8 and httpd2. The latest patch level of everything RH8 basically. The config of the cgi-global is: Location /cgi-global SetHandler perl-script PerlHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location Output of perl -V and httpd -V are below and not that this is a vhost using named vhosts via the directive NameVirtualHost *. If you need anything else let me know since I do not have the script on my system you set up for posting bug reports. (RH did not include it) Examples can be seen at http://dev.terranovum.com/cgi-global/500.pl or http://dev.terranovum.com/bad-link Thomas Bolioli PS: Any idea if there will be a replacement for Apache::Status? #httpd -V Server version: Apache/2.0.40 Server built: Oct 9 2002 08:01:13 Server's Module Magic Number: 20020628:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt 2002 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm' ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.2.92' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Sep 1 2002 23:56:49
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Terra Info wrote: I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request which makes no sense since the only log entry is File does not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl example below you get Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. Looks like ModPerl::Registry is not handling correctly the return status , hence you get the run of the default handler as well. I'll look into it. But first, does it work properly with mod_perl 1.0? Finally please attach the script that fails, preferrably removing all but the very minimal code that allows to reproduce the problem. Thanks. And if you can a test to modperl-2.0/ModPerl-Registry/t that reproduces the problem, that would be even better. If you don't know Apache::Test, you can learn more about it at: http://perl.apache.org/docs/general/testing/testing.html and looking at the existing tests. To run the registry tests you need to cd to the ModPerl-Registry dir first and run 'make test'. If it seems like too much work, I'll take care of adding the test. But it'd be cool if people who encounter problems were able to submit tests with their reports. Thanks. __ 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
mod_perl-2 configuration problem
Hello, After adding 'LoadModule perl_module modules/mod_perl.so' and / or 'PerlRequire C:/Apache2/conf/extra.pl' to httpd.conf , my Apache (2.0.43) HTTP server fails. I am using mod_perl 1.99_08-dev. Any thought s would be greatly appreciated. Thanks, Carl Holm
RE: mod_perl-2 configuration problem
Hi - Some thoughts from a relative newbie who just recently got ap2/mp2 up and running... 1) How does is fail? Seg fault? 2) Did you add modules to Apache2 during the ap2 ./configure setp? If so, you may want to re-install it 'naked': ./configure --with-mpm=worker (-or- prefork) After you get it running you can play with adding modules. 3) Which version of Perl? 5.8.0 (I hope)? Did you perl install 'pass' the tests shown in: http://perl.apache.org/docs/2.0/user/install/install.html#Prerequisites 4) You may want to look at my experiences at: http://beaucox.com/mason/mason-with-apmp2-mini-HOWTO.htm (ignore the 'mason' part if your not using it). 5) Check that the mod_perl.so in your apache tree is the same as the moduled in the mod_perl tree (/your-path-to-modperl-2-package/src/modules/perl/mod_perl.so). Aloha = Beau. -Original Message- From: Carl Holm [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 19, 2002 12:47 PM To: [EMAIL PROTECTED] Subject: mod_perl-2 configuration problem Hello, After adding 'LoadModule perl_module modules/mod_perl.so' and / or 'PerlRequire C:/Apache2/conf/extra.pl' to httpd.conf , my Apache (2.0.43) HTTP server fails. I am using mod_perl 1.99_08-dev. Any thought s would be greatly appreciated. Thanks, Carl Holm
Re: mod_perl-2 configuration problem
On Thu, 19 Dec 2002, Carl Holm wrote: Hello, After adding 'LoadModule perl_module modules/mod_perl.so' and / or 'PerlRequire C:/Apache2/conf/extra.pl' to httpd.conf , my Apache (2.0.43) HTTP server fails. I am using mod_perl 1.99_08-dev. Any thought s would be greatly appreciated. Thanks, Carl Holm This could be a number of things ... Are there any messages printed out to the screen or in the error log? If installing by ppm, did you get a mod_perl-2 package? And did you get the right one for your Perl version? And did mod_perl.so install OK in your Apache2 modules directory? See the install page for Win32 mod_perl-2 at http://perl.apache.org/ for more details. -- best regards, randy kobes
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
Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
- Original Message - From: Stas Bekman [EMAIL PROTECTED] Cc: Ask Bjoern Hansen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:07 AM Subject: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks) Actually, returning to Issac's question regarding releasing the handler early, you need a slightly modified version of the cl filter to do that. Since it's already buffering the data, you just want to do this unconditionaly. How do you mean unconditionaly? BTW: I'm wondering whether the solutnio for the whole buffering thing is write a buffer filter or is this something that should be done internally within the brigades? After all, once the [mod_perl] response handler (or filter) passes the EOS bucket, it's not needed anymore, and who cares if the other filters are ready or not? Stas, it sounded to me like you were suggesting something like: mod_perl handler/filter---Filter API---buffer filtercore-outputclient The assumption is that if bufer_filter slurps up the data, it will release the previous filters' resources, but I think that's kinda backwards thinking. As far as I understand, the only buffer you EVER have to worry about is the data coming IN to your filter. Once you pass the buckets along, you never have to worry about them again. 2 conclusions on this (my thought process included :-)): 1) The seemingly correct thing to do here would be to ensure that a handler/filter's resource pool (and entire thread?) is cleaned up as soon as it's done running. I think the latter is true, and to do this properly, Apache'd really have to give each filter plugged into each request it's own running thread. That's gonna add lotsa overhead. Maybe just a flag to request it's own thread if the module author/user is expecting their handler/filter to really use heavy resources (like an on-the-fly image processing filter for example). That way, heavy modules can get their own resources for when their eneded and release them ASAP. 2) The flipside of this is that a heavy module (like discussed above) *would* need this buffer filter; but it would want the buffer to slurp up the data coming *in*. The idea would be to let these heavy modules *create* themselves only when the data is ready (to optimize resource allocation/usage). The problem with this is that it's useless. Each request, as I understand, requires each filter in the chain to register itself in the bucket brigade chain right at the offset - which means that the private thread idea can't work since it will have to create the thread at the beginning of the request anyway - certainly before the data is ready. Comments? Issac
Re: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
[Issac's view snipped] Rather than commenting on your view Issac, please allow me to try again to explain how I think it works, hopefully more clear this time: Let's forget for a moment about buckets inside bridades, and call the brigades themselves entities that are passed along. Now think of a realworld fireman water bucket brigade, everybody passes a bucket (entity) and usually there are several buckets (entities) moving at the same time. Now let's imagine that the first man in the brigade picks a new bucket only when the last man has poured its bucket out. So at any given moment there is only one bucket (entity) moving along the brigade. This is exactly the situation with httpd. In the current httpd filtering model one entity is moving along the filters stack and no new entity will enter the stack, before the one on the stack will leave it (go to the client if we are talking about output filters). I didn't want to use the httpd buckets and brigades in this example, because they make my comparison confusing. In the real world there is one brigade and many buckets. In httpd, there are many bridages that are moving along the stack of filters (and each brigade have one or more buckets, which are irrelevant to this particular discussion). Hope this clearifies the picture. The conclusion: If the filter stack is busy processing some data and the response handler hasn't finished sending the data, it'll block waiting for the filter stack to return and only then hand over the next chunk of data. At least that's how it appears to the filters. Now if you want to play with it, it should be a trivial thing to do. Just take some response handler that generates a lot of data in a loop and prints some logs to STDERR on each iteration, then insert a filter that passes the brigades unmodified (like MyApache::FilterSnoop does) but has a 'sleep 3' statement. I expect that the response handler will block on each sleep. I hope that my understanding was correct :) Also allow me to suggest that reading the following section: http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter and trying the MyApache::FilterSnoop module at work should clearify a lot. __ 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: newbie:How to get form input in mod_perl 2 since Apache::requestis not implemented yet ?
BuffaloRC Club wrote: Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. If you want to play with 2.0 it's cool, but you may find that it's not yet ready for production, as not all APIs are available yet. On the other hand 1.27 is a *very* robust version. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Apache::compat is the only way to go for now (if you don't use CGI.pm). See http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_content_ Apache::Request for Apache 2.0 is in works. The C version is pretty much completed, but it's not clear how it's going to be distributed. Once this clears out the perl glue code will be written. Join the [EMAIL PROTECTED] if you want to help and be the first one to know of new developments. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:stas;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: How to parse after reading POST data in mod_perl 2 ?
Thanks Philippe for the tip.
After looking at Apache2::Apache::compat and some
input from Randy Kobes, I came up with the following
package called getform.pm which gets the form data
into a hash without using Apache::compat.
(Hope it will help some newbie !!):
package ModPerl::getform;
use strict;
use Apache::Reload;
sub handler {
my $r = shift;
$r-content_type('text/html');
my $form_input;
# Read in the form - data
#
$r-read($form_input,$r-headers_in-{'Content-length'});
$r-setup_client_block;
print Error unless $r-should_client_block;
$r-get_client_block($form_input,$r-headers_in-{'Content-length'});
my @args = map {
s/%([0-9a-fA-F]{2})/pack(c,hex($1))/ge;
s/\+/ /g;
$_;
} split /[=;]/, $form_input, -1;
my %input;
while (my ($name,$value) = splice @args,0,2) {
push @{$input{$name}}, $value;
}
$r-send_http_header;
print BRI got the following info:BRBR;
foreach (keys %input) {
print $_ = @{$input{$_}}BR;
}
return Apache::OK;
}
1;
Thanks guys,
This is a great list.
Sumitro Chowdhury.
--- Philippe M. Chiasson [EMAIL PROTECTED] wrote:
On Fri, 2002-11-01 at 03:41, Sumitro Chowdhury
wrote:
Hi all,
Please help ...
Using Apache/2.0.43 (Unix) mod_perl/1.99_07-dev
Perl/v5.8.0 .
I read in POST data from Form using
$r-read($buff,$r-headers_in-{'Content-length'})
Since I donot use Apache::compat, what API methods
are
available to parse this string data ? ( possibly
convert it to a hash )
There isn't anything readily avaliabe for the
moment, but take a look
at parse_args() in Apache::compat for a good working
example.
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Should I be coding with mod_perl 2 yet?
Hi there, On 1 Nov 2002, Clinton Gormley wrote: I'm struggling to get anything much working with mod_perl 2. [snip] I have read all of the documentation on perl.apache.org. Are you sure? :) If these things should be working, Well it does say on the home page that it's the Bleeding Edge. where can I find out how to use them? Here. mod_perl for Apache 2.x is still at the development stage, but people are using it. You can more specific help if you ask a more specific question (but you won't get it from me, I haven't even looked at Apache 2.x yet:). 73, Ged.
Re: Should I be coding with mod_perl 2 yet?
Clinton Gormley wrote: I'm struggling to get anything much working with mod_perl 2. I have installed mod_perl 1.99_07 with Apache 2.0.43. I have read all of the documentation on perl.apache.org. I can get a basic page returned to me with a modperl handler, but as soon as I try to do anything of note (eg Apache-push_handlers() (or should that be Apache2-push_handlers()? - neither works), get query string parameters, etc) I run into a brick wall. I've only started to dabble with mod_perl 2, but I didn't find it too difficult. the real drawback was that whereas mod_perl 1.0 use()d most of the classes for you behind the scenes (like Apache::Table), with mod_perl 2.0 you need to use() them yourself, which means you have to figure out which classes provide which methods. my only work to date can be found here: http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-Clean-2.00b.tar.gz Apache::Clean is a PerlOutputFilterHandler, but the tests include two simple PerlResponseHandlers, and it's pretty well commented, so it should serve as a starting point for which classes you're likely to need. I found all the classes I needed by grep'ing the t/ directory in the mod_perl distribution for the methods in question, adding them one by one, then, when it worked, checking the source for the module in question to learn what was going on... --Geoff
Re: Should I be coding with mod_perl 2 yet?
Hi, well I have read all (whatever scanty little available) docs on mod_perl 2 and am pretty disappointed. For example Apache::Request is not ready yet so you need Apache::compat and mod_perl 1 for basic POST request handling and parsing. In my opinion, stay with mod_perl 1. -Sumitro Chowdhury. --- Ged Haywood [EMAIL PROTECTED] wrote: Hi there, On 1 Nov 2002, Clinton Gormley wrote: I'm struggling to get anything much working with mod_perl 2. [snip] I have read all of the documentation on perl.apache.org. Are you sure? :) If these things should be working, Well it does say on the home page that it's the Bleeding Edge. where can I find out how to use them? Here. mod_perl for Apache 2.x is still at the development stage, but people are using it. You can more specific help if you ask a more specific question (but you won't get it from me, I haven't even looked at Apache 2.x yet:). 73, Ged. __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: Should I be coding with mod_perl 2 yet?
On Fri, 1 Nov 2002, Sumitro Chowdhury wrote: Hi, well I have read all (whatever scanty little available) docs on mod_perl 2 and am pretty disappointed. Additions, I'm sure, are welcome :) For example Apache::Request is not ready yet so you need Apache::compat and mod_perl 1 for basic POST request handling and parsing. In my opinion, stay with mod_perl 1. They're working on libapreq for Apache2, and as has been pointed out, mod_perl-2 is still in the development stage. For basic form handling, though, you can use my %args = $r-Apache::args; -- best regards, randy kobes
Re: Should I be coding with mod_perl 2 yet?
--- Randy Kobes [EMAIL PROTECTED] wrote:
On Fri, 1 Nov 2002, Sumitro Chowdhury wrote:
Hi,
well I have read all (whatever scanty little
available) docs on mod_perl 2 and am pretty
disappointed.
Additions, I'm sure, are welcome :)
For example Apache::Request is not ready yet so
you
need Apache::compat and mod_perl 1 for basic POST
request handling and parsing.
In my opinion, stay with mod_perl 1.
They're working on libapreq for Apache2, and as has
been
pointed out, mod_perl-2 is still in the development
stage. For basic form handling, though, you can use
my %args = $r-Apache::args;
H
I thought POST request handling needs
$r-read($buf,$r-headers_in-{'Content-length'})
and GET request handling needs
$r-args();
Thank you, Randy for the quick response. Since I have
watched your contribution to the list, I was hoping if
you could discuss {setup,should,get}_client_block API
for handling POST data on this list.
Inspite of all my rantings, I still use mod_perl 2.0
;-)
Thanks again,
Sumitro Chowdhury
--
best regards,
randy kobes
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: Should I be coding with mod_perl 2 yet?
On Fri, 1 Nov 2002, Sumitro Chowdhury wrote:
H
I thought POST request handling needs
$r-read($buf,$r-headers_in-{'Content-length'})
and GET request handling needs
$r-args();
Sorry about that - I should have read more carefully that
you were specifically referring to POSTed data -
my %args = $r-Apache::args;
is for GET requests. For POST, as is described in the
content() method of Apache::compat, for now one can use
$r-setup_client_block;
# return an error unless $r-should_client_block;
my $len = $r-headers_in-get('content-length');
my $buf;
$r-get_client_block($buf, $len);
my %args = map {
s/%([0-9a-fA-F]{2})/pack(c, hex($1))/ge;
$_;
} split /[=;]/, $buf, -1;
Some of the issues regarding, in particular, using the
mod_perl-1-ish $r-args and $r-content in an array context
are discussed at
http://perl.apache.org/docs/2.0/user/compat/compat.html
But you do have a point that life will be easier when libapreq
is ready :)
--
best regards,
randy
Re: Should I be coding with mod_perl 2 yet?
--- Randy Kobes [EMAIL PROTECTED] wrote:
my %args = $r-Apache::args;
is for GET requests. For POST, as is described in
the
content() method of Apache::compat, for now one can
use
$r-setup_client_block;
# return an error unless $r-should_client_block;
my $len = $r-headers_in-get('content-length');
my $buf;
$r-get_client_block($buf, $len);
my %args = map {
s/%([0-9a-fA-F]{2})/pack(c, hex($1))/ge;
$_;
} split /[=;]/, $buf, -1;
Just to help real newbies like me , we can also add
+ substitution so that the above line becomes:
my %args = map {
s/%([0-9a-fA-F]{2})/pack(c, hex($1))/ge;
s/\+/ /g;
$_;
} split /[=;]/, $buf, -1;
Thanks a lot, Randy.
Regards,
Sumitro Chowdhury.
Some of the issues regarding, in particular, using
the
mod_perl-1-ish $r-args and $r-content in an array
context
are discussed at
http://perl.apache.org/docs/2.0/user/compat/compat.html
But you do have a point that life will be easier
when libapreq
is ready :)
--
best regards,
randy
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
How to parse after reading POST data in mod_perl 2 ?
Hi all,
Please help ...
Using Apache/2.0.43 (Unix) mod_perl/1.99_07-dev
Perl/v5.8.0 .
I read in POST data from Form using
$r-read($buff,$r-headers_in-{'Content-length'})
Since I donot use Apache::compat, what API methods are
available to parse this string data ? ( possibly
convert it to a hash )
Cannot use params() from Apache::Request since I have
not installed mod_perl 1.
Thanks,
Sumitro Chowdhury
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
newbie:How to get form input in mod_perl 2 since Apache::request is not implemented yet ?
Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q-param() etc? I can get form data thru $r-read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Thanks in advance. Sumitro Chowdhury.Do you Yahoo!? HotJobs - Search new jobs daily now
[MP2] Net::LDAP/Convert::ASN1 and mod_perl 2
I'm using Mod_perl (1.99_07), Apache 2, and using the threaded MPM. I have ithreads installed and most everything works excellently. I am having a problem using Net::LDAP- specifically with $ldh-add() operations. $ldh-search() works fine, $ldh-modify also seems to work. Has anyone else experienced this? Is there a simple solution or fix? Further investigation reveals that the hang occurs within a sysread() in Convert::ASN1::asn_read() [within the IO.pm] I would suspect some interactions between threads/Net::LDAP/Convert:ASN1 -- except it only happens on -add operations.
Problem with CGI.pm and mod_perl 2
Hi,
I have a problem when porting an application from Apache 1.23.x + mod_perl
1.0 to Apache 2.xx + mod_perl 2.0.
One of the scripts receives as argument a filename (with no path info), and
the scripts is suppose to open the file from the same directory in which
the script is located and perform some stuff on it. The code looks
something like:
$cgih = new CGI;
$filename = $cgih-param('filename');
open(FILE, $filename) || die can't open file;
# do some stuff
This code used to work on previous platform, i.e. the file called
filename would be opened from the same directory as the script itself.
Now, the system cannot anymore. If I hardcode the filename with full path,
it works (this was to check whether I had some file permission problems).
Thanks,
Luc
Re: Problem with CGI.pm and mod_perl 2
On Wed, 16 Oct 2002 [EMAIL PROTECTED] wrote:
Hi,
I have a problem when porting an application from Apache 1.23.x + mod_perl
1.0 to Apache 2.xx + mod_perl 2.0.
One of the scripts receives as argument a filename (with no path info), and
the scripts is suppose to open the file from the same directory in which
the script is located and perform some stuff on it.
[ ... ]
This code used to work on previous platform, i.e. the file called
filename would be opened from the same directory as the script itself.
Now, the system cannot anymore. If I hardcode the filename with full path,
it works (this was to check whether I had some file permission problems).
As you've discovered, assuming a value for the current working
directory isn't reliable. Apart from using the full path, one
possibility is to use FindBin, which gives the directory of the
original script, and you can then specify paths relative to that.
However, the perl-5.8 man page for FindBin warns, in part,
If there are two modules using FindBin from different directories
under the same interpreter, this won't work. Since FindBin uses
BEGIN block, it'll be executed only once, and only the first caller
will get it right. This is a problem under mod_perl and other persistent
Perl environments, where you shouldn't use this module. Which also means
that you should avoid using FindBin in modules that you plan to put on
CPAN. The only way to make sure that FindBin will work is to force the
BEGIN block to be executed again:
delete $INC{'FindBin.pm'};
require FindBin;
--
best regards,
randy kobes
Re: install/config mod_perl-2(1.99_08)
On Thu, 3 Oct 2002, Paul Simon wrote: If I try to call index.cgi under /test/index.cgi, the page just hangs. index.cgi works as a straight CGI page. Here it is: #!C:/Perl/bin/Perl.exe print Content-type: text/plain\n\n; print mod_perl 2.0 rocks!\n; [ .. ] I just upgraded all the Win32 binaries on our site for both mod_perl-2 and mod_perl-1, including the ppm files and the all-in-one packages, to use the latest Apache sources (2.0.43 and 1.3.27), in light of the security concerns in older versions. All the mod_perl tests for the various packages passed on my system, and in particular simple registry scripts work OK with perl-5.6.1 and this mod_perl-2 - you may want to give this a try. Note that the mod_perl version hasn't changed with these upgrades, so if you install via ppm, you may have to uninstall the current package first, or else force the install. -- best regards, randy
install/config mod_perl-2(1.99_08)
Is there something in the configuration not jiving? Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm) In http.conf I have:Include conf/test.confAddHandler cgi-script .cgiIn test.conf I have:PerlRequire "C:/Apache2/conf/startup.pl"Location /test/ Options +ExecCGI SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders/Location#ScriptAlias /test/ "C:/Apache2/htdocs/test/" startup.pl looks like:#!C:/Perl/bin/Perl.exeuse Apache2();use ModPerl::Registry ();1; Apache starts up. I can see mod_perl loaded in via server-status. And when I call just the directory /test/, this what I get in the error log: [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not found or unable to stat If I try to call index.cgi under /test/index.cgi, the page just hangs.index.cgi works as a straight CGI page. Here it is:#!C:/Perl/bin/Perl.exe print "Content-type: text/plain\n\n"; print "mod_perl 2.0 rocks!\n"; --- I'll keep trying. Hopefully, there's an easy solution to this. Thanks.Do you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Re: install/config mod_perl-2(1.99_08)
On Thu, 3 Oct 2002, Paul Simon wrote: Is there something in the configuration not jiving? Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm) In http.conf I have: Include conf/test.conf AddHandler cgi-script .cgi In test.conf I have: PerlRequire C:/Apache2/conf/startup.pl Location /test/ Options +ExecCGI SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders /Location #ScriptAlias /test/ C:/Apache2/htdocs/test/ startup.pl looks like: #!C:/Perl/bin/Perl.exe use Apache2(); use ModPerl::Registry (); 1; Apache starts up. I can see mod_perl loaded in via server-status. And when I call just the directory /test/, this what I get in the error log: [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not found or unable to stat This is OK - you normally don't want a directory listing for locations that have scripts in them. If I try to call index.cgi under /test/index.cgi, the page just hangs. index.cgi works as a straight CGI page. Here it is: #!C:/Perl/bin/Perl.exe print Content-type: text/plain\n\n; print mod_perl 2.0 rocks!\n; --- I'll keep trying. Hopefully, there's an easy solution to this. Thanks. Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I found the above to also hang ... However, it worked as expected using the perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz under ftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues with threads on Win32 with perl-5.6.1, eventually perl-5.8 will be the recommended Win32 Perl for mod_perl-2; if possible, you may want to give this a try. -- best regards, randy kobes
RE: install/config mod_perl-2(1.99_08)
You say eventually perl 5.8 will be recommended. Why is it not the recommended version now? I am developing a windows application currently and started out with activestate perl 5.6.1, apache 2, and mod_perl 1.99. I ran into a lot of problems and blamed them on mod_perl because it is still rather new. Things have progressed smoothly enough using apache versions 1.x and mod_perl 1.x I didn't think of trying perl 5.8, but would be glad to if that is going to help things. I would like the capabilities that Apache and mod_perl 2.x give. Ben -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 8:30 AM To: Paul Simon Cc: [EMAIL PROTECTED] Subject: Re: install/config mod_perl-2(1.99_08) Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I found the above to also hang ... However, it worked as expected using the perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz under ftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues with threads on Win32 with perl-5.6.1, eventually perl-5.8 will be the recommended Win32 Perl for mod_perl-2; if possible, you may want to give this a try. -- best regards, randy kobes
RE: install/config mod_perl-2(1.99_08)
On Thu, 3 Oct 2002, Ben Mathews wrote: You say eventually perl 5.8 will be recommended. Why is it not the recommended version now? That's really Doug's call, but perhaps one consideration holding back a recommendation of 5.8 on Win32 is that ActiveState won't be making a perl-5.8 binary in the immediate future, and may wait until a 5.8.1 is released (5.8 and 5.6 aren't binary compatable, so this is a major step). And there are some portability things, for example, with unicode - some modules which rely on the way 5.6.1 deals with this need changes with 5.8. I am developing a windows application currently and started out with activestate perl 5.6.1, apache 2, and mod_perl 1.99. I ran into a lot of problems and blamed them on mod_perl because it is still rather new. Things have progressed smoothly enough using apache versions 1.x and mod_perl 1.x I didn't think of trying perl 5.8, but would be glad to if that is going to help things. I would like the capabilities that Apache and mod_perl 2.x give. Ben I've found that using 5.8 often is more stable than 5.6.1, as far as mod_perl-2 goes - it's definitely worth trying out for development. -- best regards, randy
Re: install/config mod_perl-2(1.99_08)
Randy Kobes <[EMAIL PROTECTED]>wrote: On Thu, 3 Oct 2002, Paul Simon wrote: Is there something in the configuration not jiving? Windows 2000, Apache 2.0.42, mod_perl-2(1.99_08-dev via ppm) In http.conf I have: Include conf/test.conf AddHandler cgi-script .cgi In test.conf I have: PerlRequire "C:/Apache2/conf/startup.pl" Options +ExecCGI SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders #ScriptAlias /test/ "C:/Apache2/htdocs/test/" startup.pl looks like: #!C:/Perl/bin/Perl.exe use Apache2(); use ModPerl::Registry (); 1; Apache starts up. I can see mod_perl loaded in via server-status. And when I call just the directory /test/, this what I get in the error log: [error] 1932: ModPerl::Registry: C:/Apache2/htdocs/test/ not found or unable to statThis is OK - you normally don't want a directory listingfor locations that have scripts in them. If I try to call index.cgi under /test/index.cgi, the page just hangs. index.cgi works as a straight CGI page. Here it is: #!C:/Perl/bin/Perl.exe print "Content-type: text/plain\n\n"; print "mod_perl 2.0 rocks!\n"; --- I'll keep trying. Hopefully, there's an easy solution to this. Thanks.Maybe not easy :) Using perl-5.6.1, and Apache-2.0.42, I foundthe above to also hang ... However, it worked as expected usingthe perl-5.8/Apache2 binary of perl-5.8-win32-bin.tar.gz underftp://theoryx5.uwinnipeg.ca/pub/other/. As there's issues withthreads on Win32 with perl-5.6.1, eventually perl-5.8 will be therecommended Win32 Perl for mod_perl-2; if possible, you may wantto give this a try.-- best regards,randy kobes Almost easy. I have it running now with perl5.8.I'm going to pilot it...Thanks.PaulDo you Yahoo!? New DSL Internet Access from SBC & Yahoo!
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
.--[ Ask Bjoern Hansen wrote (2002/09/19 at 01:47:39) ]-- | | On Wed, 18 Sep 2002, Josh Chamas wrote: | | [...] | So I run it again with ServerTokens Min, and get the same results. :) | Still something different on the mod_perl headers, looks like mod_perl | 2.x is setting Content-Length where it didn't use to. | | The details evade me, but I recall something about how the buckets | work in the httpd that makes httpd 2.0 always know (and set) the | Content-Length. | | There was discussion about changing it; but I don't remember the | outcome. | | (yes, it has (had?) some implications for how data can be streamed | from the proxy in such a setup, which was the reason for changing | it. Indeed it could be that it was only affecting the proxy. Did I | mention that I forgot the details?). :-) | | - ask | | -- | ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do(); `- Would this mean that a handler that currently cannot know it's Content-Length: ( due to the way it handles templates ) would not have to be re-written on Apache/mod_perl 2.0? Wouldn't this make it only necessary to determine the Last-Modified: header to make caching work? I've been wanting to put front-end caches on my mod_perl handlers for some time but the code changes necessary to generate these two headers have kept me from it for some time. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
On Wed, 18 Sep 2002, Josh Chamas wrote: [...] So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. The details evade me, but I recall something about how the buckets work in the httpd that makes httpd 2.0 always know (and set) the Content-Length. There was discussion about changing it; but I don't remember the outcome. (yes, it has (had?) some implications for how data can be streamed from the proxy in such a setup, which was the reason for changing it. Indeed it could be that it was only affecting the proxy. Did I mention that I forgot the details?). :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
On the Apache 2.0 note, 2.0 breaks terribly when it has to proxy chunked data. It strips the chunk length and does not replace it with a Content-Length. Bug is filed but no one in the Apache group seems to want to play with it :( Just a warning for those of you who may potentially be doing proxy for chunked data. John- On Thu, 19 Sep 2002 01:47:39 -0700 (PDT) Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Wed, 18 Sep 2002, Josh Chamas wrote: [...] So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. The details evade me, but I recall something about how the buckets work in the httpd that makes httpd 2.0 always know (and set) the Content-Length. There was discussion about changing it; but I don't remember the outcome. (yes, it has (had?) some implications for how data can be streamed from the proxy in such a setup, which was the reason for changing it. Indeed it could be that it was only affecting the proxy. Did I mention that I forgot the details?). :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
mod_perl 2.x vs. mod_perl 1.x benchmarks
Hey mod_perl users, I just did a benchmarks to compare mod_perl + apache versions 1 2. What I find striking is that without any optimizations, the v2 mod_perl apache are faster. I'm really blown away, as I was expecting the new versions to be slower with v1 configurations. Here's the numbers in brief: Apache/1.3.26 + mod_perl/1.27 + perl 5.6.1 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1420.710 70.390.000704 322 5062 mod_perl handlerhello.ben 942.510106.100.001061 206 7660 Apache/2.0.40 + Perl/v5.8.0 + mod_perl/1.99_05-dev Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1619.710 61.740.000617 290 5912 mod_perl handlerhello.ben 1210.110 82.640.000826 194 11070 The mod_perl benchmark was run with the Apache::compat layer and the perl-script directive in Apache 2.x, so it was not optimized. Further, the configs between the web servers were identical on my linux server during the benchmarks, so Apache was not optimized at all for v2. on top of that, the mod_perl2 was loaded as a DSO while mod_perl1 was compiled statically. Again, I'm amazed. Obviously the apache mod_perl development teams have done an awesome job in building this next generation server. Regards, Josh
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? - Perrin
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Perrin Harkins wrote: Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? Looks like its the Server tokens, see below. 32 bytes! Maybe on a benchmark this small, this makes a difference? *sigh* So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. Apache/1.3.26 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1417.5 42531 30.000.000705 250 5000 mod_perl handlerhello.ben 939.1 28181 30.010.001065 134 7244 Apache/2.0.40 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1602.4 48236 30.100.000624 250 6756 mod_perl handlerhello.ben 1177.3 36062 30.630.000849 154 11648 -- Josh === Old headers throwing static HTML bytes off HTTP/1.1 200 OK Date: Wed, 18 Sep 2002 20:14:59 GMT Server: Apache/2.0.40 (Unix) mod_perl/1.99_05-dev Perl/v5.8.0 Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-7363e840 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html HTTP/1.1 200 OK Date: Thu, 19 Sep 2002 01:02:20 GMT Server: Apache/1.3.26 (Unix) Resin/2.1.2 PHP/4.2.1 mod_perl/1.27 mod_ssl/2.8.9 OpenSSL/0.9.6b Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-3a32fbd9 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html
Re: win32 apache2.0.40 mod_perl-2
On Fri, 16 Aug 2002, Paul Simon wrote: They do work as ordinary CGI scripts (thank goodness!). The same scripts worked under ModPerl::Registry before I upgraded everything. There are no messages in the error logs. If I call the cgi page under ModPerl::Registry via a browser, it just hangs seemingly forever... I can try installing a simple hello world handler, skipping ModPerl::Registry, and see if that works... Hi Paul, I just uploaded a new mod_perl-2 ppm package to http://theoryx5.uwinnipeg.ca/ppmpackages/ which you may want to try - this was still compiled against apache-2.0.40, but constains a few changes to mod_perl-2 since the earlier ppm package (you may have to uninstall the old mod_perl-2 package before installing this one, as the version hasn't changed). This was compiled with ActivePerl 633. All the tests still pass with this version, but occasionally I get errors about Windows running low on virtual memory (this doesn't arise with perl-5.8). If you still have problems with this version about things hanging, try closing as many apps as possible to free up some memory. -- best regards, randy
