Re: Trouble with Apache::Request
On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? -- best regards, randy
Re: file upload object - getting form field name
Sorry for the latte reply.
Absolutely:
[snip]
**use Apache::Request;
**my $q=Apache::Request-instance($r);
my $upload_id = 0;
**for my $upload ($q-upload) {
$upload_id++;
**my $name=$upload-name;
# do stuff
}
[snip]
All the best,
Issac
[mp1] PerlCleanupHandler in .htaccess file sometimes doesn't run
I've run into an interesting bug in mp1. If I have a PerlCleanupHandler
defined in a .htaccess file, then it won't run if there was a
PerlInitHandler defined in httpd.conf. It doesn't matter what the
PerlInitHandler does, as long as its there the cleanup fails. If I have
the init handler run from within the .htaccess, its all fine, and it
also works if I have a PerlLogHandler in .htaccess instead of a
PerlCleanupHandler.
I'll attach two test files. Foo.pm is loading via PerlModule in
httpd.conf, and I have |PerlInitHandler Foo-init|. I first noticed this
with Apache::Reload, but any init handler will do it.
With the init handler, I get lines in error_log for init, Request, and
cleanup1. Without, I get lines for Request, cleanup1, and then the die.
The cleanup1 handler was just for testing; removing it doesn't affect
the results.
I'm testing with RH9's perl 5.8.0, and cvs mod_perl/1.27_01-dev from
about 12 hours ago, with a self compiled apache_1.3.27. This also
happened with mp/1.27, but doesn't happen with mp2 (After I port my test
modules to mp2). mod_perl is built as a .so with
perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs
EVERYTHING=1
Thanks,
Bradley
PS Is there a way to subscribe to this list so that I can post, but not
receive any mails? I couldn't find a nomail option on the list page at
perl.apache.org. I've subscribed to the digest version for now.
package Foo;
use Apache;
sub init($$) : method {
warn init;
return Apache::OK;
}
sub cleanup($$) : method {
die XXX;
return Apache::OK;
}
1;
#!/usr/bin/perl -w
use lib qw(.);
use strict;
use warnings;
use Foo;
sub cleanup1 {
warn cleanup1;
return Apache::OK;
}
Apache-request-register_cleanup(\cleanup1);
Apache-request-send_http_header('text/plain');
warn Request;
print HI!;
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
#PerlInitHandler Foo-init
PerlCleanupHandler Foo-cleanup
HTML::Mason and mod_perl issues with DSO?
With regard to the RT (http://www.fsck.com/rt) program, there were notes in the README file that said mod_perl DSO has/had massive scalability problems when using HTML::Mason. I inquired to the RT author, who isn't certain that issues till persists - so I also inquired to the HTML::Mason people. However, I wanted to also inquire -here- since some people might know more about the problem - I guess it had to do with random segfaults - and I imagine this might be in larger-scale operations (ie: the reference to scalability) so the problem might not be seen unless the system has a larger load. I'm not sure. Any info/tips/pointers on this issue would be appreciated. Forrest
Re: is anybody using mp2 in production?
Our mod_perl success story. As consultants we were hired to repair, revamp and rebuild a online classifieds site in which a lot of cost and effort was placed in promoting the site and generating traffic but the site itself was based on a 3rd party product that simply could not handle the half million hits a day the site was getting. Without a lot of effort the decision was made to build a custom solution from the ground up using Perl and Apache under Linux. After completing the project and having some difficult issues with the current ISP we moved the entire site to an ISP that we have had a long term relationship with and who provides us with everything one would need to properly maintain such a project. Little did we know that the second we moved to our new ISP it was like opening up the flood gates (long story relating to other ISP), overnight this CGI driven site went from a half million hits a day to a million and with it came a number of problems, a lot of which were unfixable without adding more hardware - there was simply far too much traffic coming through during the peak times of the day. Having spent a week doing everything we could, optimizing everything possible it was clear that at best, we may be able to gain enough to just keep our heads above water. Reluctantly we knew we had no choice but to give mod_perl a try, we really didn't think it was going to make that much of a difference but every little bit counted at this point. We knew that it was going to be very difficult to setup apache and especially convert our code over - I mean after all I've heard as many stories of nightmare conversions as success stories. After about the first week of pouring through the documentation and experimenting on our development server, I realized HOW WRONG I WAS.. Once we understood what was expected, conversion of the current code was less painful and a lot more interesting to do then some of the phone calls or meetings that led up to getting the contract for the project itself J. Once everything was done we could see instantly the improvement on our dev server, what we didn't know nor what we were prepared for was what would happen once this was running in production, I mean sure it was fast when there is only 2 of us on the machine, so was the old site. What we saw after going live was one of those moments when you are just blown away, where you are sitting there saying I see it but I just don't believe it. At our best estimate we gained more then a 300% performance increase, during peak hours we were seeing load times of 20 - 30, processing going defunct etc. etc. prior to mod_perl. Since the day we went live we haven't seen the machines even sweat, even the DB machine was impacted by the change in a positive way. We are currently up over 2 million hits a day, the 1 million hits gained since going live with mod_perl has resulted in practically nothing (everything is still saying Give me More!!!) We'd like to think it was easy moving to mod_perl because we are such awesome coders, but of course the truth is it's due to the awesome documentation at http://perl.apache.org, the fantastic support of mod_perl in all those perl modules we have all come to depend on, the invaluable mailing lists and mailing list archives, and what I personally think is the coolest thing of all, Stas Bekman who never left me or anyone else I've seen on the mailing list hanging for any answer. We have just completed a re-design of the site and have been up and running under Apache 2 and mod_perl 2 for about 6 months now with as few problems as anyone could ever hope to have. Mod_perl is clearly the solution for high traffic sites, however because of our experience with mod_perl we have since done everything in it, from the simplest of form mailers to complex sites because in my eyes there is no reason not to do things the best possible way the first time around! Thanks to Everyone on the Mod_perl Team Chris Faust Developer of http://www.isoldmyhouse.com - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 08, 2003 1:50 AM Subject: is anybody using mp2 in production? I've heard that some people are already using mod_perl 2.0 in production. It'd be interesting to hear mp2 both success and failure stories. p.s. mod_perl 1.99_09, which includes new features and lots of bug fixes, should be released as soon as the current cvs is stabilized. So testing the current cvs and reporting any problems (especially build/test ones) would be helpful to make the new release better. About the same time Apache::Test should be released on CPAN. __ 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
PerlOptions Clone/Parent in mp2
wrt Apache 2.0, mod_perl 2.0... I'm not using Clone or Parent at the current time, but I was re-reading the documentation on them for an unrelated reason and started thinking about how they would work. Suppose I want to set up five virtual hosts with modules A - E. Then I want to set up six virtual hosts with modules F - M. The first five virtual hosts can all share a pool of interpreters and the second six virtual hosts can share a different pool of interpreters. How might I declare two parent interpreters globally, one with modules A - E and the other with modules F - M such that I could share a pool of interpreters derived from the first parent with five virtual hosts and a pool of interpreters derived the second parent with a different six virtual hosts? This is all theoretical, I don't actually need this right now, and probably won't ever. Just trying to imagine how these options would be used. mma
Re: is anybody using mp2 in production?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Faust wrote: Our mod_perl success story. Here's mine... The company I work at makes network management appliances (with a web interface). We were trying to figure out a good way to demo them without having to ship embedded PCs to everyone... I went looking all over for good open-source filtering proxies that are easily configurable, and happened upon very little. Then I remembered reading about apache2 and how you can now hook into every part of the request process now. I grabbed mp2 and in the span of 4 hours (and having no previous experience with buckets and such) had prototyped a filtering proxy that is perfect for our needs. I was able to set it up so that a virtual host can be mapped to an appliance behind the proxy and it automatically proxies all incoming connections to that appliance, *and* filters the returning data back out to the client. It also lets us have live filters on anything coming back from the appliances, so we're able to make the appliances work just like they would out in the field, but still filter data to disallow doing things that could do damage to our internal test network for the appliances (like performing level 3 vulnerability scans and such). Thanks, mod_perl! grin - -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ Standards are the industry's way of codifying obsolescence. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+46MAUu+jZtP2Zf4RAmbzAKCHyOog0l+0AFGFA1KzUn1ZsjcUhQCfa7qB QI31bJNthwssxFC5eA34oXA= =uPqa -END PGP SIGNATURE-
install upgrade for mod_perl+apache 2.046 onto apache 2.044 question
I have apache 2.044 installed on win2k. I want to install the mod_perl which comes with apache included (version 2.046).What do I need to do with the current 2.044 version before installing the new version? Do I uninstall it, stop it, or nothing?Once I install the new version what are the steps to revert back to the old version if I run into problems?This is an active site, so I do not want to figure this out by experimentation, if possible.Thanks for any guidance.dan Do you Yahoo!? Free online calendar with sync to Outlook(TM).
Re: install upgrade for mod_perl+apache 2.046 onto apache 2.044 question
Hi - - Original Message - From: dan martin To: [EMAIL PROTECTED] Sent: Sunday, June 08, 2003 11:08 AM Subject: install upgrade for mod_perl+apache 2.046 onto apache 2.044 question I have apache 2.044 installed on win2k. I want to install the mod_perl which comes with apache included (version 2.046).What do I need to do with the current 2.044 version before installing the new version? Do I uninstall it, stop it, or nothing? Once I install the new version what are the steps to revert back to the old version if I run into problems?This is an active site, so I do not want to figure this out by experimentation, if possible.Thanks for any guidance.dan It's been a while since I've installed on Windows, but here goes: 1. Wait 'till the wee hours. 2. Stop your current server. 3. Uninstall the service (apache -k uninstall (?)). 4. Back it up. 5. If memory serves, Apache 2 is pretty well self contained in one directory; C:\Apache2 (?). Rename this directory to something like C:\Apache2.old 6. Download/install your new Apache2. 7. Copy your configuration file(s) from old to new - you shouldn't have to make any changes between 44 and 46. Don't worry about setting up mod_perl yet. 8 Start your new server and test. 9. If all is well, install the service (apache -k install (?)) and reboot and test again. Now you can move on to mod_perl. To revert: 1. Stop new 2. Uninstall service. 3. rename C:\Apache2 to C:\apache2.new 4. rename C:\Apache2.old to C:\Apache2. 5. install service. 6. start old. THIS IS NOT A GOOD WAY TO FLY. I strongly recommend getting a testing server setup on a different box so that you can make changes such as this without interrupting your active site. You SHOULD be able to experiment with the new software without fear of disrupting your traffic! If there is no way you can do that, please drop me an off-list email and perhaps I can let you install/test remotely on one of my windows boxes. Aloha = Beau;
Re: Compiling mod_perl as a static module....
Subject: Returned mail: see transcript for details The original message was received at Sun, 8 Jun 2003 23:22:26 +0100 from IDENT:[EMAIL PROTECTED] [212.22.195.7] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 553 5.3.0 Zone rejected due to abuse.) - Transcript of session follows - ... while talking to forrie.com.: MAIL From:[EMAIL PROTECTED] 553 5.3.0 Zone rejected due to abuse. == Hi there, As you can see mail from me doesn't reach you directly. What's this abuse? On Sun, 8 Jun 2003, Forrest Aldrich wrote: I'm finally getting down to trying this out, per your directions. As I recall I have already asked you to keep your messages on the List. Please read http://perl.apache.org/maillist/email-etiquette.html 73, Ged.
Re: Trouble with Apache::Request
On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? Well, I've recompile a fresh version of Perl 5.8.0 (without threads), Apache, mod_perl and PHP and still no luckon that box. I have another Mandrake 9.0 box and tried to compile the new libapreq that Stas pointed to from CVS and got the following errors Any suggestions? I did: perl Makefile.PL -httpd /usr/sbin/httpd make test And got: In file included from apache_request.c:59: apache_request.h:5:19: httpd.h: No such file or directory apache_request.h:6:25: http_config.h: No such file or directory apache_request.h:7:23: http_core.h: No such file or directory apache_request.h:8:22: http_log.h: No such file or directory apache_request.h:9:23: http_main.h: No such file or directory apache_request.h:10:27: http_protocol.h: No such file or directory apache_request.h:11:25: util_script.h: No such file or dmake[1]: Leaving directory `/root/tmp/httpd-apreq/c' pache_request.h:38: parse error before table apache_request.h:38: warning: no semicolon at end of struct or union apache_request.h:47: parse error before '*' token apache_request.h:47: warning: data definition has no type or storage class apache_request.h:49: parse error before '}' token apache_request.h:49: warning: data definition has no type or storage class apache_request.h:56: parse error before table apache_request.h:56: warning: no semicolon at end of struct or union apache_request.h:57: warning: data definition has no type or storage class apache_request.h:59: parse error before '*' token apache_request.h:59: warning: data definition has no type or storage class apache_request.h:60: parse error before '}' token apache_request.h:90: parse error before '*' token apache_request.h:90: parse error before '*' token apache_request.h:90: warning: data definition has no type or storage class apache_request.h:91: parse error before '*' token apache_request.h:92: parse error before '*' token apache_request.h:93: parse error before '*' token apache_request.h:94: parse error before '*' token apache_request.h:95: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: parse error before '*' token apache_request.h:96: warning: data definition has no type or storage class apache_request.h:97: parse error before '*' token apache_request.h:98: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: parse error before '*' token apache_request.h:101: warning: data definition has no type or storage class apache_request.h:102: parse error before '*' token apache_request.h:102: parse error before '*' token apache_request.h:102: warning: data definition has no type or storage class apache_request.h:104: parse error before '*' token apache_request.h:104: parse error before '*' token apache_request.h:104: warning: data definition has no type or storage class apache_request.h:105: parse error before '*' token apache_request.h:124: parse error before '*' token apache_request.h:127: parse error before '*' token In file included from apache_request.c:60: apache_multipart_buffer.h:16: parse error before request_rec apache_multipart_buffer.h:16: warning: no semicolon at end of struct or union apache_multipart_buffer.h:29: parse error before '}' token apache_multipart_buffer.h:29: warning: data definition has no type or storage class apache_multipart_buffer.h:31: parse error before '*' token apache_multipart_buffer.h:32: parse error before request_rec apache_multipart_buffer.h:32: warning: data definition has no type or storage class apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: parse error before '*' token apache_multipart_buffer.h:33: warning: data definition has no type or storage class apache_multipart_buffer.h:34: parse error before '*' token apache_multipart_buffer.h:35: parse error before '*' token apache_multipart_buffer.h:36: parse error before '*' token apache_request.c:61: parse error before '*' token apache_request.c:69: parse error before '*' token apache_request.c: In function `util_read': apache_request.c:71: `request_rec' undeclared (first use in this function) apache_request.c:71: (Each undeclared identifier is reported only once apache_request.c:71: for each function it appears in.) apache_request.c:71: request for member `r' in something not a structure or union apache_request.c:72: `OK' undeclared (first use in this function) apache_request.c:74: `REQUEST_CHUNKED_ERROR' undeclared (first use in this
Compling mod_perl as a static module....
I'm finally getting down to trying this out, per Ged's directions. I want to try compiling mod_perl statically - I believe APACI is for DSO only - when I try to run perl Makefile.PL, I get warnings about compiling SSI with a DSO, thus I believe the following might need to be modified (removing APACI for?). (again, this is under FreeBSD-4.8 with the latest mod_ssl and 1.27-mod-perl) My process has been thus far: o untar all distributions o copy my custom config.layout to apache directory and ./configure (no other options) o enter to mod_ssl directory and configure, export SSL_BASE=SYSTEM o enter into mod_ssl directory this is where I'm at. I presume I don't need to pass APACI options to specify that which I already placed in my config.layout under the apache source tree. Thanks, Forrest [ makepl_args.mod_perl ] USE_APACI=1 APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.27/src DO_HTTPD=1 EVERYTHING=1 ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1 APACI_ARGS=--with-perl=/usr/local/bin/perl APACI_ARGS=--enable-module=rewrite APACI_ARGS=--enable-module=include APACI_ARGS=--enable-module=info APACI_ARGS=--enable-module=usertrack APACI_ARGS=--server-gid=nogroup APACI_ARGS=--suexec-docroot=/usr/local/apache/htdocs APACI_ARGS=--enable-module=most APACI_ARGS=--enable-module=auth_db APACI_ARGS=--enable-module=mmap_static APACI_ARGS=--enable-shared=max APACI_ARGS=--enable-module=ssl APACI_ARGS=--enable-rule=SHARED_CORE APACI_ARGS=--activate-module=src/modules/dosevasive/libdosevasive.a
Re: HTML::Mason and mod_perl issues with DSO?
From: Forrest Aldrich [EMAIL PROTECTED] With regard to the RT (http://www.fsck.com/rt) program, there were notes in the README file that said mod_perl DSO has/had massive scalability problems when using HTML::Mason. This is probably old info based on the DSO build shipped through RedHat 7.2. Somewhere as an update to the 7.2 release they got it right and it is solid at least through 7.3 and its updates. The only quirk is that there is a memory leak if you attempt graceful restarts so it is always best to stop/start. I'm not sure about RH8/9 with apache 2.x/mp2. --- Les Mikesell [EMAIL PROTECTED]
Re: Trouble with Apache::Request
On Sun, 8 Jun 2003, K Old wrote: On Sun, 2003-06-08 at 01:50, Randy Kobes wrote: On Fri, 7 Jun 2003, K Old wrote: [ .. ] Stas, thanks for your reply. I downloaded the CVS source and it still failed all tests. Below is the output from make test and the output from perl -V. Any help is appreciated! Another thing that may be worth trying - if you've installed libapreq, try going back to the mod_perl sources and running those tests again. Do the modules/request.t and modules/cookie.t tests pass, or if not, do you receive the same errors? Well, I've recompile a fresh version of Perl 5.8.0 (without threads), Apache, mod_perl and PHP and still no luckon that box. I have another Mandrake 9.0 box and tried to compile the new libapreq that Stas pointed to from CVS and got the following errors Any suggestions? I did: perl Makefile.PL -httpd /usr/sbin/httpd make test And got: In file included from apache_request.c:59: apache_request.h:5:19: httpd.h: No such file or directory [ .. ] Is /usr/sbin/httpd is a symbolic link to a real httpd, which could be something like /usr/local/httpd/bin/httpd? And is this httpd the one you compiled? If so, try giving the full path to this httpd as the Makefile.PL argument (there should be a /usr/local/httpd/include/ directory which has the header (.h) files that couldn't be found). -- best regards, randy
Re: install upgrade for mod_perl+apache 2.046 onto apache 2.044question
On Sun, 8 Jun 2003, Beau E. Cox wrote: Hi - - Original Message - From: dan martin To: [EMAIL PROTECTED] Sent: Sunday, June 08, 2003 11:08 AM Subject: install upgrade for mod_perl+apache 2.046 onto apache 2.044 question I have apache 2.044 installed on win2k. I want to install the mod_perl which comes with apache included (version 2.046). What do I need to do with the current 2.044 version before installing the new version? Do I uninstall it, stop it, or nothing? Once I install the new version what are the steps to revert back to the old version if I run into problems? This is an active site, so I do not want to figure this out by experimentation, if possible. It's been a while since I've installed on Windows, but here goes: 1. Wait 'till the wee hours. 2. Stop your current server. 3. Uninstall the service (apache -k uninstall (?)). 4. Back it up. 5. If memory serves, Apache 2 is pretty well self contained in one directory; C:\Apache2 (?). Rename this directory to something like C:\Apache2.old 6. Download/install your new Apache2. 7. Copy your configuration file(s) from old to new - you shouldn't have to make any changes between 44 and 46. Don't worry about setting up mod_perl yet. 8 Start your new server and test. 9. If all is well, install the service (apache -k install (?)) and reboot and test again. Now you can move on to mod_perl. To revert: 1. Stop new 2. Uninstall service. 3. rename C:\Apache2 to C:\apache2.new 4. rename C:\Apache2.old to C:\Apache2. 5. install service. 6. start old. I don't really have much to add to what Beau nicely summarized, save for, if you're installing the Perl/Apache/mod_perl package from http://perl.apache.org/dist/win32-bin/, you should also back up your present Perl directory in the same way as you'll do for Apache2. There's a configuration script that'll be run in this package which will change some conf files based on your installed location, so it's easiest to install things to their final destinations before running this. But before installing this package, as Beau said, rename your current Apache2 and Perl directories, so as nothing gets overwritten by the install. -- best regards, randy kobes
CGI.pm not processing POST within AuthenHandler
For some reason, CGI.pm (2.93) does not seem to parse POST data within a
PerlAuthenHandler. For example, the following:
sub handler {
my $r = shift;
my $q = new CGI($r);
my @params = $q-param;
$r-server-log-error(handler params are . join ::, @params);
return Apache::OK;
}
logs the paramter names correctly if the request is a GET, but not if a
POST. The same code works fine within an Apache::Registry script, which
I assume will have the same behavior as a PerlResponseHandler. I also
attempted both the x-www-form-urlencoded and multipart/form-data POST
types and neither worked.
Am I missing something that mod_perl is not doing till the response
phase, like setting up STDIN? I thought that this might have had
something to do with an earlier thread
(http://marc.theaimsgroup.com/?t=10499295465r=1w=2), however I
also tried adding:
$r-subprocess_env;
Apache-request($r);
to the handler to no avail.
Thanks
-Mike
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_09 Perl/v5.8.0 CGI.pm/2.93
Directory /home/*/public_html/protected
FilesMatch \.pl$
AllowOverride None
Options +ExecCGI
SetHandler perl-script
PerlAuthenHandler Apache::MyAuth::handler
AuthType Cookie
AuthName MyPrivateStuff
require valid-user
PerlResponseHandler ModPerl::Registry
/FilesMatch
/Directory
Re: CGI.pm not processing POST within AuthenHandler
Michael L. Artz [EMAIL PROTECTED] writes:
For some reason, CGI.pm (2.93) does not seem to parse POST data within a
PerlAuthenHandler. For example, the following:
sub handler {
my $r = shift;
my $q = new CGI($r);
my @params = $q-param;
$r-server-log-error(handler params are . join ::, @params);
return Apache::OK;
}
[...]
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_09 Perl/v5.8.0 CGI.pm/2.93
Attempting to read POST data before the content-handler is called
is unsafe with httpd-2. You'll probably have to wait for
Apache::Request to be ported over in order to do something like that.
--
Joe Schaefer
Re: is anybody using mp2 in production?
That's cool is yet another example of the power of mod_perl. And you're right about the documentation. I was blown away by the amount of docs. available at perl.apache.org; thanks to all the hard work of Stas Beckman !! We had been using mod_perl had been having a very stable site for quite a long time. Now we're planning to shift to mod_perl-2. I could get everything compiled, but mp2 bombed while parsing our config. files. I've reported this bug (search for PerlSection + recurse/recursive) and hopefully some1 is working on it ;-) Anyway, I plan to spend my weekends reading mod_perl code and see if I can fix this issue. Once the above issue is fixed, we'd be able to move on to the next level of testing report any further issues. (Btw, Chris, are you using the worker mpm ? Is it stable ? We'd like to go the worker mpm way would like to know if any1 is using it yet in production.) thx Sreeji --- Chris Faust [EMAIL PROTECTED] wrote: Our mod_perl success story. As consultants we were hired to repair, revamp and rebuild a online classifieds site in which a lot of cost and effort was placed in promoting the site and generating traffic but the site itself was based on a 3rd party product that simply could not handle the half million hits a day the site was getting. Without a lot of effort the decision was made to build a custom solution from the ground up using Perl and Apache under Linux. After completing the project and having some difficult issues with the current ISP we moved the entire site to an ISP that we have had a long term relationship with and who provides us with everything one would need to properly maintain such a project. Little did we know that the second we moved to our new ISP it was like opening up the flood gates (long story relating to other ISP), overnight this CGI driven site went from a half million hits a day to a million and with it came a number of problems, a lot of which were unfixable without adding more hardware - there was simply far too much traffic coming through during the peak times of the day. Having spent a week doing everything we could, optimizing everything possible it was clear that at best, we may be able to gain enough to just keep our heads above water. Reluctantly we knew we had no choice but to give mod_perl a try, we really didn't think it was going to make that much of a difference but every little bit counted at this point. We knew that it was going to be very difficult to setup apache and especially convert our code over - I mean after all I've heard as many stories of nightmare conversions as success stories. After about the first week of pouring through the documentation and experimenting on our development server, I realized HOW WRONG I WAS.. Once we understood what was expected, conversion of the current code was less painful and a lot more interesting to do then some of the phone calls or meetings that led up to getting the contract for the project itself J. Once everything was done we could see instantly the improvement on our dev server, what we didn't know nor what we were prepared for was what would happen once this was running in production, I mean sure it was fast when there is only 2 of us on the machine, so was the old site. What we saw after going live was one of those moments when you are just blown away, where you are sitting there saying I see it but I just don't believe it. At our best estimate we gained more then a 300% performance increase, during peak hours we were seeing load times of 20 - 30, processing going defunct etc. etc. prior to mod_perl. Since the day we went live we haven't seen the machines even sweat, even the DB machine was impacted by the change in a positive way. We are currently up over 2 million hits a day, the 1 million hits gained since going live with mod_perl has resulted in practically nothing (everything is still saying Give me More!!!) We'd like to think it was easy moving to mod_perl because we are such awesome coders, but of course the truth is it's due to the awesome documentation at http://perl.apache.org, the fantastic support of mod_perl in all those perl modules we have all come to depend on, the invaluable mailing lists and mailing list archives, and what I personally think is the coolest thing of all, Stas Bekman who never left me or anyone else I've seen on the mailing list hanging for any answer. We have just completed a re-design of the site and have been up and running under Apache 2 and mod_perl 2 for about 6 months now with as few problems as anyone could ever hope to have. Mod_perl is clearly the solution for high traffic sites, however because of our experience with mod_perl we have since done everything in it, from the simplest of form mailers to complex sites because in my eyes there is no reason
[mp1] 1.28 release candidate #1
Finally, the first mod_perl 1.28 release candidate #1 has arrived. It
can be downloaded here:
http://www.apache.org/~gozer/mp1/mod_perl-1.27_01-dev-rc1.tar.gz
MD5 : ad64dfdb4f5b056b00d87288ef31bd56
SHA1: 03409c6f44c408acae44a258fe4e59b408c0040f
The summary of what has changed since 1.27 are (from STATUS):
Add Win32 support to Apache::SizeLimit [Matt Phillips
[EMAIL PROTECTED] and Mohamed Hendawi [EMAIL PROTECTED]]
Change Apache::SizeLimit to not push a cleanup handler if already in
the cleanup handler phase, and adjust docs to show that cleanup
handler is the preferred phase to use [Perrin Harkins
[EMAIL PROTECTED]]
Rename Apache::test to Apache::testold because Apache::test on
case-insensitive systems will collide with Apache::Test which
supercedes Apache::test. So if you want to keep on using Apache::test,
either bundle it with your project (putting it under inc/ or t/ so it
won't be installed) or require mod_perl 1.28 and use Apache::testold
instead. Of course the best route is to port your test suite to use
a much better Apache::Test which work with mod_perl 1.0 and 2.0.
[Philippe M. Chiasson, Stas Bekman]
Tweak mod_perl.h to defined _INCLUDE_APACHE_FIRST only after apache
headers were included [Stas Bekman]
avoid various warnings under src/modules/perl/:
- declare bufsiz to be STRLEN in Apache.xs, and add
STRLEN to Apache/typemap
- add I32 typecast in Constants.xs
- avoid use of unregistered local variables for Win32
in mod_perl.c and perl_config.c
- s/I32/U8/ in mod_perl.h, perl_config.c, and perl_util.c
- declare i and http_code to be STRLEN in perl_util.c
[Stas Bekman, Randy Kobes]
don't use $r variable in Apache::PerlRun::compile(), so the script
won't use use inherited $r by mistake [Stas Bekman]
define PERL_DIRECTIVE_HANDLERS so that ModuleConfig.c gets
generated when building on Win32 within Visual Studio
[John Petrakis [EMAIL PROTECTED]]
enable PERL_SECTIONS for Win32 [Dirk Maetens [EMAIL PROTECTED]]
use touch() from ExtUtils::Command, rather than a system touch(),
for the benefit of platforms without touch(). [Randy Kobes
[EMAIL PROTECTED]]
can't let the default typemap rule to convert sv into char* in
unescape_url, since it doesn't handle correctly undefs (returns an
unallocated string, which then causes a segfault in
ap_unescape_url. use SvPV_force, instead, which does the right
thing. [Stas Bekman]
Make sure to start perl, if it's not running, before processing Perl*
directives, with threaded perl and PERL_STACKED_HANDLERS=0 [Stas
Bekman]
Add Apache::Module to Bundle::Apache [Stas Bekman]
use $Config{'installstyle'} instead of hardcoded 'lib', to handle
Makefile.PL's PREFIX option correctly [Philippe M. Chiasson
[EMAIL PROTECTED]]
prevent segfaults in mod_perl_mark_where() when a sub can't get
resolved [Gerald Richter [EMAIL PROTECTED]]
Apache::Status: Need to load B::Terse/TerseSize if it wasn't loaded
yet in that child before using it. [Dan Sully [EMAIL PROTECTED]]
document the server_root_relative() method [Stas Bekman [EMAIL PROTECTED]]
eliminate warnings when flushing functions with empty () prototypes in
Apache::PerlRun::flush_namespace [Yair Lenga [EMAIL PROTECTED]]
fix Apache::Status to not use :: in filenames, which is not allowed on
certain OSs [DH [EMAIL PROTECTED]]
various cygwin fixes [Per Einar Ellefsen [EMAIL PROTECTED]]
fix to compile with 5.8.0 on win32 [Randy Kobes [EMAIL PROTECTED]]
Document the possible misuses of the Apache::Constant constants
[Per Einar Ellefsen [EMAIL PROTECTED]]
--
A more detailled review of each patch included in this release candidate can be found
here:
http://www.apache.org/~gozer/mp1/1.27-dev/
Please give this release a spin and report back any problems or failed tests to:
[EMAIL PROTECTED] as soon as possible. The more platforms configurations, the
merrier!
Thank you!
--
-- -
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+5BRtyzKhB4jDpaURAuoOAJ9G1hIWGKHJxdidMrPBvyuRCawTSQCcDnvp
xxhgPZh8Rir59NYKXIQmyJI=
=zZNt
-END PGP SIGNATURE-
signature.asc
Description: This is a digitally signed message part
