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: 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: 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
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: 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
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
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
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 (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: 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();
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: mod_perl 2 apache 2?
Michael Wojcikiewicz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone tried getting mod_perl to work in Apache v2 (the latest beta?)... Just a quick try resulted in mod_perl2 trying to compile against apache 1.3.20... Wasnt mod_perl v2 supposed to be for Apache v2?... modperl 2.x is in development and if you want to play with it, you have to read *its* docs to figure out how to install it. modperl 1.x won't work with httpd 2.x. So either use 1x's or 2x's but don't mix the two. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl 2.x/perl 5.6.x ?
On Tue, Apr 25, 2000 at 07:08:00PM -0700, Doug MacEachern wrote: The biggest hurdle I've faced until now is that DBI won't build with this threaded perl. Hopefully DBI will be updated since the latest version is from july 99. it compiles with the patch below, not sure if it actually works though :) Just tried it here and aside from some warnings it compiled and passed all its tests. Can't say whether it works or not though as Msql-Mysql doesn't compile, you got a patch hiding for that somewhere too :-) PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ? -- I'm as confused as a baby in a topless bar. Mike Hall, Unix Admin - Rock Island Communications [EMAIL PROTECTED] System Admin - riverside.org[EMAIL PROTECTED]
Re: mod_perl 2.x/perl 5.6.x ?
On Wed, Apr 26, 2000 at 01:32:29AM -0700, Doug MacEachern wrote:
Just tried it here and aside from some warnings it compiled and passed all
its tests. Can't say whether it works or not though as Msql-Mysql doesn't
compile, you got a patch hiding for that somewhere too :-)
sure :) again, just compiles, not sure if it works.
PS: Mind if I post your message/patch on 'dbi-users' for Tim's benefit ?
not at all, but i doubt either patch is quite right (the mysql one esp. is
a quick hack)
Geez, I wasn't actually expecting a patch (just hoping maybe :-) and here
one is ! What can I say besides restating an earlier comment some else
posted recently "** You're the man **" !!
I don't know if the patches are quite right as you say, but both patches
(DBI, Msql-Mysql) compiled, passed their tests and after moving a couple
of scripts and databases over to the 'play' box they worked fine accessing
the mysql databases, displaying, inserting, and deleting records. Its just
a simple database-based GuestBook, nothing major but if its any indication
things appear to work fine with your patches.
I held off posting either of them to 'dbi-users' until I could do some
testing but since they seem to work I'm going to go ahead and post them
over there so the authors can take a peek, review, etc.
PS: I did find a patch Tim had posted for DBI, it didn't work for DBI but
it did work for Msql-Mysql. Looks like either your Msql-Mysql patch
or Tim's DBI patch work for Msql-Mysql, the common key seems to be
defining 'dbis', although they do it in different ways. I stuck with
your patches for both to keep things consistent. Tim's patch is below:
Index: DBI-1.1301/DBIXS.h
Prereq: 10.11
*** DBI-1.13/DBIXS.hMon Jul 12 03:04:28 1999
--- DBI-1.1301/DBIXS.h Tue Jul 13 23:01:22 1999
***
*** 1,4
! /* $Id: DBIXS.h,v 10.11 1999/07/12 02:02:33 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
--- 1,4
! /* $Id: DBIXS.h,v 10.12 1999/07/13 22:01:12 timbo Exp $
*
* Copyright (c) 1994, 1995, 1996, 1997, 1998, 1999 Tim Bunce England
*
***
*** 397,407
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t * get_dbistate() {
! return ((dbistate_t*)SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (get_dbistate())
#else /* plain and simple non perl object / multiplicity case */
# define DBISTATE_DECLARE static dbistate_t *DBIS
--- 397,410
# define DBISTATE_DECLARE
# define DBISTATE_INIT
! static dbistate_t **get_dbistate() {
! return ((dbistate_t**)SvIVX(DBISTATE_ADDRSV));
}
! # define DBIS (*get_dbistate())
+ /* temporary for drivers that mistakenly use 'dbis' instead of 'DBIS' */
+ # define dbis (*get_dbistate())
+
#else /* plain and simple non perl object / multiplicity case */
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Leslie Mikesell wrote: So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? no, -Dusethreads with 5.6.0 makes the Perl runtime (aka PerlInterpreter), re-entrant. all of Perl's internal globals (symbol table, stacks, etc.) become part of the PerlInterpreter structure, each interpreter clone has it's own copy of any writeable data (symbol table, stacks, etc.) the syntax tree is shared. this makes it possible to concurrently call subroutines in different threads, which was not possible with 5.005_03. this doesn't solve the problem of xs modules or c libraries that are not thread-safe, we'll have to fix any trouble makers as they pop up.
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gunther Birznieks wrote: I agree... but to some degree I hope this has been done for many of the major modules and the major DBI modules (eg DBD sybase)... as they ended up having to work on ActiveState's PerlEx which uses a similar model. In a way, PerlEx's model has been a test for mod_perl 2.0. indeed. PerlEx uses PERL_OBJECT, which is similar in concept to USE_ITHREADS. we all owe a great deal of thanks to ActiveState for sponsoring Gurusamy Sarathy's work on 5.6.0. without the USE_ITHREADS implementation, mod_perl would be next to useless with threaded apache-2.0
RE: mod_perl 2.x/perl 5.6.x ?
On Sat, 22 Apr 2000, Eric Cholet wrote:
mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns
on threading and multiplicity.
just to be clear, as you mention below, -Dusetheads isn't required for
mod_perl-2.0, but strongly suggested if you use an mpm other than prefork :)
and i wouldn't say -Dusethreads "turns on threading", it simply makes the
Perl runtime re-entrant (as explained in an earlier message)
The biggest hurdle I've faced until now is
that DBI won't build with this threaded perl. Hopefully DBI will be updated
since the latest version is from july 99.
it compiles with the patch below, not sure if it actually works though :)
This is for using Apache 2.0's pthread MPM, of course you can build perl
5.6 non threaded and use apache 2.0's prefork model but then it's not
as exciting :-)
maybe not as exciting, but still very important, the 1.3.x model works
quite well for many people, so mod_perl-2.0 will continue to support it.
--- DBI.xs~ Sun Jul 11 19:04:27 1999
+++ DBI.xs Tue Apr 25 19:05:40 2000
@@ -9,6 +9,13 @@
#include "DBIXS.h" /* DBI public interface for DBD's written in C */
+#ifndef pTHX_
+#define aTHXo_
+#define CopFILEGV(cop) cop-cop_filegv
+#define CopLINE(cop) cop-cop_line
+#define get_sv perl_get_sv
+#endif
+
#define MY_VERSION "DBI(" XS_VERSION ")"
#if (defined USE_THREADS || defined PERL_CAPI || defined PERL_OBJECT)
@@ -112,7 +119,7 @@
# if (PATCHLEVEL == 4) (SUBVERSION 68)
# define dPERINTERP_SV \
-SV *perinterp_sv = perl_get_sv(MY_VERSION, FALSE)
+SV *perinterp_sv = get_sv(MY_VERSION, FALSE)
# else
# define dPERINTERP_SV \
SV *perinterp_sv = *hv_fetch(PL_modglobal, MY_VERSION, \
@@ -121,7 +128,7 @@
# define dPERINTERP_PTR(T,name)\
T name = (T)(perinterp_sv SvIOK(perinterp_sv) \
- ? SvIVX(perinterp_sv) : NULL)
+ ? (T)SvIVX(perinterp_sv) : NULL)
# define dPERINTERP\
dPERINTERP_SV; dPERINTERP_PTR(PERINTERP_t *, PERINTERP)
# define INIT_PERINTERP \
@@ -189,13 +196,13 @@
DBIS-size= sizeof(*DBIS);
DBIS-xs_version = DBIXS_VERSION;
/* publish address of dbistate so dynaloaded DBD's can find it */
-sv_setiv(perl_get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
+sv_setiv(get_sv(DBISTATE_PERLNAME,1), (IV)DBIS);
DBISTATE_INIT; /* check DBD code to set DBIS from DBISTATE_PERLNAME*/
DBIS-logfp= stderr;
DBIS-debug= 0;
-DBIS-neatsvpvlen = perl_get_sv("DBI::neat_maxlen", GV_ADDMULTI);
+DBIS-neatsvpvlen = get_sv("DBI::neat_maxlen", GV_ADDMULTI);
sv_setiv(DBIS-neatsvpvlen, 400);
/* store some function pointers so DBD's can call our functions*/
DBIS-getcom= dbih_getcom;
@@ -613,7 +620,7 @@
if (imp_size == 0) {
/* get size of structure to allocate for common and imp specific data */
char *imp_size_name = mkvname(imp_stash, "imp_data_size", 0);
- imp_size = SvIV(perl_get_sv(imp_size_name, 0x05));
+ imp_size = SvIV(get_sv(imp_size_name, 0x05));
if (imp_size == 0)
imp_size = g_imp_maxsize + 64;
}
@@ -1450,16 +1457,16 @@
fprintf(logfp," during global destruction.");
return;
}
-if (!curcop-cop_line) {
+if (!CopLINE(curcop)) {
fprintf(logfp," at unknown location!");
return;
}
-file = SvPV(GvSV(curcop-cop_filegv), len);
+file = SvPV(GvSV(CopFILEGV(curcop)), len);
if (trace_level=4) {
if ( (sep=strrchr(file,'/')) || (sep=strrchr(file,'\\')))
file = sep+1;
}
-fprintf(logfp," at %s line %ld.", file, (long)curcop-cop_line);
+fprintf(logfp," at %s line %ld.", file, (long)CopLINE(curcop));
}
@@ -1751,7 +1758,7 @@
*/
I32 markix = TOPMARK;
CV *xscv = GvCV(imp_msv);
- (void)(*CvXSUB(xscv))(xscv);/* Call the C code directly */
+ (void)(*CvXSUB(xscv))(aTHXo_ xscv); /* Call the C code directly */
if (gimme == G_SCALAR) {/* Enforce sanity in scalar context */
if (++markix != stack_sp - stack_base ) {
@@ -2130,7 +2137,7 @@
Fflush(DBILOGFP);
}
DBIS-debug = level;
- sv_setiv(perl_get_sv("DBI::dbi_debug",0x5), level);
+ sv_setiv(get_sv("DBI::dbi_debug",0x5), level);
}
}
OUTPUT:
@@ -2226,7 +2233,7 @@
}
if (type == '$') { /* lookup scalar variable in implementors stash */
char *vname = mkvname(DBIc_IMP_STASH(imp_xxh), meth, 0);
- SV *vsv = perl_get_sv(vname, 1);
+ SV *vsv = get_sv(vname, 1);
if (trace)
fprintf(DBILOGFP,"- %s = %s\n", vname, neatsvpv(vsv,0));
ST(0) = sv_mortalcopy(vsv);
RE: mod_perl 2.x/perl 5.6.x ?
So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So the Perl modules itself need not to be thread safe. Perl 5.6 has some nice features to clone a Perl interpreter in a efficent way (syntax tree of modules (loaded before clone) is used by all cloned Perl interpreters, while the data is separate for all cloned Perl interpreters). mod_perl 2.0 get manages a pool of cloned Perl interpreters which is assigns as neccessary to the Apache threads. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: mod_perl 2.x/perl 5.6.x ?
At 02:51 PM 4/23/00 +0200, Gerald Richter wrote: So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So the Perl modules itself need not to be thread safe. Perl 5.6 has some nice features to clone a Perl interpreter in a efficent way (syntax tree of modules (loaded before clone) is used by all cloned Perl interpreters, while the data is separate for all cloned Perl interpreters). mod_perl 2.0 get manages a pool of cloned Perl interpreters which is assigns as neccessary to the Apache threads. In the end, there may still be some threading issues that should be watched out for I suspect. If mod_perl 2.0 follows a similar design to ActiveState's PerlEx, PerlEx also has some problems when the Perl modules themselves link to stuff that is not threadsafe as a shared library. eg, every 2 weeks or so, the PerlEx mailing list has someone post "I get mysterious crashes with Win32::ODBC"... and the perennial reply of "Don't use that module with PerlEx as it's not threadsafe"... I don't know if there is anything else that might cause a similar problem. Later, Gunther
RE: mod_perl 2.x/perl 5.6.x ?
On Sun, 23 Apr 2000, Gerald Richter wrote: So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So the Perl modules itself need not to be thread safe. Perl 5.6 has some nice features to clone a Perl interpreter in a efficent way (syntax tree of modules (loaded before clone) is used by all cloned Perl interpreters, while the data is separate for all cloned Perl interpreters). mod_perl 2.0 get manages a pool of cloned Perl interpreters which is assigns as neccessary to the Apache threads. I suspect that two things are going to happen here. The CPAN community is going to have to turn the crank one more time to update popular modules to work under this environment. DBI and its drivers are going to be particularly important. Secondly, this Perl environment is going to reveal things that people never considered doing before, and some new and useful modules will be added to our arsenal. But first, Apache 2.0 will need to get out the door. -jwb
RE: mod_perl 2.x/perl 5.6.x ?
At 09:59 AM 4/23/00 -0700, Jeffrey W. Baker wrote: On Sun, 23 Apr 2000, Gerald Richter wrote: So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? No, mod_perl 2.0 assign a "full" Perl interpreter to every Apache thread. So the Perl modules itself need not to be thread safe. Perl 5.6 has some nice features to clone a Perl interpreter in a efficent way (syntax tree of modules (loaded before clone) is used by all cloned Perl interpreters, while the data is separate for all cloned Perl interpreters). mod_perl 2.0 get manages a pool of cloned Perl interpreters which is assigns as neccessary to the Apache threads. I suspect that two things are going to happen here. The CPAN community is going to have to turn the crank one more time to update popular modules to work under this environment. DBI and its drivers are going to be particularly important. Secondly, this Perl environment is going to reveal things that people never considered doing before, and some new and useful modules will be added to our arsenal. I agree... but to some degree I hope this has been done for many of the major modules and the major DBI modules (eg DBD sybase)... as they ended up having to work on ActiveState's PerlEx which uses a similar model. In a way, PerlEx's model has been a test for mod_perl 2.0. Caveat to my statement: I am not a Perl internals guru. So what I say is conjecture and hope rather than what will definately happen when mod_perl 2.0 comes out. Later, Gunther
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: This is for using Apache 2.0's pthread MPM, of course you can build perl 5.6 non threaded and use apache 2.0's prefork model but then it's not as exciting :-) Does apache 2.0 let you run a prefork model under NT? Les Mikesell [EMAIL PROTECTED]
RE: mod_perl 2.x/perl 5.6.x ?
This is for using Apache 2.0's pthread MPM, of course you can build perl 5.6 non threaded and use apache 2.0's prefork model but then it's not as exciting :-) Does apache 2.0 let you run a prefork model under NT? NT has it's own MPM which is threaded prefork ... Multi Process Model with Preforking (Apache 1.3) dexter Multi Process Model with Threading via Pthreads Constant number of processes, variable number of threads mpmt_pthread .. Multi Process Model with Threading via Pthreads Variable number of processes, constant number of threads/child (= Apache/pthread) spmt_os2 .. Single Process Model with Threading on OS/2 winnt . Single Process Model with Threading on Windows NT I believe the first 3 run only under Unix. -- Eric
Re: mod_perl 2.x/perl 5.6.x ?
On Sat, Apr 22, 2000 at 11:59:58AM +0200, Eric Cholet wrote: though. Can anybody in the know, shed some light on this, just trying to save some work down the road as I'd like to upgrade to the perl 5.6 stuff now and use it with my existing mod_perl (I already use the CVS version and I know thats required for perl 5.6) but I really don't want to have recompile perl (and modules, etc) again later if I can build it the way it will need to be now and continue using mod_perl 1.x and then just upgrade to mod_perl 2.x down the road. mod_perl-2.0 requires perl 5.6 to be build with -Dusethreads, which turns on threading and multiplicity. The biggest hurdle I've faced until now is that DBI won't build with this threaded perl. Hopefully DBI will be updated since the latest version is from july 99. This is for using Apache 2.0's pthread MPM, of course you can build perl 5.6 non threaded and use apache 2.0's prefork model but then it's not as exciting :-) Thinking about it now after your message and it makes sense. I've actually been a bit lazy and still have one of the older CVS versions (pre alpha) of Apache 2.0, guess I don't know about the alphas but I was playing with both the threaded, dexter MPM's. Since dexter is kind of a hybrid but uses threads I assume it'll also need a threaded perl then. At one time I did build a threaded perl but ran into problems here and there with various modules, etc. Don't recall having any problems with DBI but then again it wasn't perl 5.6 either, that is kind of a show stopper though :-( All in all I guess I found out the answer, might just as well go for it and build 5.6 threaded, grab the lastest Apache 2.x alpha and take what comes. Its my play box anyways so I guess I can live with some things being broken :-) -- Didn't I see your picture on a milk carton ? Mike Hall, Unix Admin - Rock Island Communications [EMAIL PROTECTED] System Admin - riverside.org[EMAIL PROTECTED]
Re: mod_perl 2.x/perl 5.6.x ?
According to Eric Cholet: Does apache 2.0 let you run a prefork model under NT? NT has it's own MPM which is threaded prefork ... Multi Process Model with Preforking (Apache 1.3) dexter Multi Process Model with Threading via Pthreads Constant number of processes, variable number of threads mpmt_pthread .. Multi Process Model with Threading via Pthreads Variable number of processes, constant number of threads/child (= Apache/pthread) spmt_os2 .. Single Process Model with Threading on OS/2 winnt . Single Process Model with Threading on Windows NT I believe the first 3 run only under Unix. So, does that still leave mod_perl serializing access until everything is rewritten to be thread-safe? Les Mikesell [EMAIL PROTECTED]
