Re: Re: Need help to configue mod_perl
I am trying to configure mod_perl2.0. but Apache used to get stop.When I enters the above lines in httpd.conf. PerlRequire "C:Program FilesApache Software FoundationApache2.2confextra.pl" ### New new line for mod_perl LoadModule perl_module modules/mod_perl.so #mod_perl - LoadFile "C:/Perl/bin/perl58.dll" [This line works.] What r the steps to configure mod_perl? My installation are: perl5.8 windows xp Apache 2.0 Sandhya. On Sun, 01 Feb 2009 23:09:38 +0530 wrote >sandhya pawar wrote: >> I have installed perl5.8 & Apache 2.2 . Also Mod_perl2.2 >> >> I have to configure mod_perl. >> When I used to add following line in httpd.conf, >> LoadModule perl_module modules/mod_perl.so >> >> Apache used to get stop. >> >> How can I check that mod_perl properly installed. & what are the steps >> to configure it.? >Thats a really broad question. > >http://perl.apache.org/docs/2.0/user/config/config.html > >If you having issues, you should provide any error output you get, your >httpd.conf (a larger portion), >and any messages in your error_log. > >-- > >1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C >Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 >Consultant - P6M7G8 Inc. http://p6m7g8.net >Senior Sys Admin - RideCharge, Inc. http://ridecharge.com >Contractor - PositiveEnergyUSA http://positiveenergyusa.com >ASF Member - Apache Software Foundation http://apache.org >FreeBSD Committer - FreeBSD Foundation http://freebsd.org > >Work like you don't need the money, >love like you'll never get hurt, >and dance like nobody's watching. >
RE: Manipulating @INC and tremendous blank page
Thank you, Mark & Perrin for your help! > > Is there a way to manipulate @INC without having to use a startup.pl in> > > Sure. For example, PERL5LIB. Yes, sure. Sorry,my question wasn't correctly formulated. Below is closer to what I was looking for and should have expressed. > Regarding relative paths, I wouldn't recommend putting your perl> libraries > inside of DOCUMENT_ROOT if you can avoid it. In fact, in our staging environment libraries are working copies from subversion, hosted one folder above the domain folders with all the vhosts and we use symlink that point to them in the cgi-bin. it's perhaps a strange way of doing things (and if there's better, i'll take!!) but we want to assume the most hostile environment possible where we cannot do what we want, with the server and with perl (as it does happen with some clients). so in case of a contrived,restricted environment, we can just plug the entire framework and have it works. If we can change things for our best and the best of our client, we will accomodate accordingly. this is a compromise between SA/maintainability/flexibility and hassle^^; > If you have to use relative paths, you want something like what Mark> Hedges > suggested. That should work for ModPerl::PerlRun, where your> code is > compiled every time. For ModPerl::Registry, you'd need to do> something like > this:> > use FindBin;> unshift @INC, "$FindBin::Bin/../lib";> > Unlike "use > lib", the unshift will run every time in Registry. Also,> if you use > RegistryPrefork you won't need FindBin at all. You can> just use '../lib'. I am using FindBin and added the FindBin::again() as recommanded in hope to switch to ModPerl::RegistryPrefork soon. I am using both use lib and unshift @INC but still, for some reasons, even with ModPerl::PerlRunPrefork got some pages that could not load and in the log, it was always due to a lib that couldn't be found. If I reload the page, it works, If I reload again sometimes it won't. Adding the startup.pl, get rid of this behavior. But I will change all use lib into unshift @INC and see how it behaves. I have to say that I do not really understand how mod_perl behaves regarding the @INC manipulation. > > I've tried also ModPerl::RegistryPrefork but got some tremendous blank > > pages> > that leaved no log at all.> > I have absolutely no clue on how to > > debug this ??> - Double-check the log file Nothing there.> - Add some warn statements to see how far it gets. I was putting print statement, but you're right should switch to warn!! as for the print statements, it seems that the index.pl print statements were executed but none of the print statements in the loaded module. so I assumed that the module wasn't loaded but do not understand sometimes it is, sometimes it is not. > - Examine the communication with the client through a proxy or Firefox plugin. I've checked it thru firebug but is there a better plugin? > I think that ModPerl::RegistryPrefork is ultimately where you want to> be, > because it will be faster. indeed!!! I guess i will have to deal with some circular references lurking here and there, sloppy old code needing rewrites,etc but this should boost the app so I definitely aim at switching to ModPerl::RegistryPrefork! I have to say that switching to ModPerl::PerlRunPrefork allowed me to improve the performance in a amasing way! Well, i have checked the performance with Apache Benchmark (ab n 100 c 5,etc) and got a boost of about 20 times the cgi version when the simulated traffic is high!! Still, the ratio is very low but that is a real improvement and am really looking forward to it! (this is true for pages that were cached with Cache::Cache but required perl to be executed in some way) Thank you very much for your fast reply ! _ 5GBのオンラインファイル保存サービス。Hotmailでファイル共有もできる！ http://clk.atdmt.com/GBL/go/msnjpqjl009077gbl/direct/01/
Re: dynamic caching
In a message dated 2009-2-14 0:39:49, phark...@gmail.com writes: >That's a huge article. Which part sounded good to you? There are >many caching tools available for mod_perl. I wish to cache a full dynamic application like Web Services (SOAP). I was thinking if it's possible to make a proxy with modperl to do that caching? Thanks. Regards. **The year's hottest artists on the red carpet at the Grammy Awards. AOL Music takes you there. (http://music.aol.com/grammys?ncid=emlcntusmusi0004)
Re: dealing with empty field names in query
- Original Message > From: Jonathan Vanasco > To: modperl > Sent: Friday, February 13, 2009 3:30:20 PM > Subject: Re: dealing with empty field names in query > > > On Feb 6, 2009, at 4:58 PM, Phil Carmody wrote: > > > In those name/value pairs, according to HTML 4 at least, the names must > > begin > with a letter [A-Za-z]. The empty string does not do so. Garbage in, garbage > out. > > > > Part of me agrees with that philosophy. > > Another part of me is more practical. > > We had to stop using libapreq2 for cookies, because we found out that > wordpress > (being a shoddy piece of software) was generating invalid cookies at times. > when apreq encountered it, it segfaulted. What version of apreq was this? And did you report it to the apreq-dev@ mailing list? > so while the engineering part of me is okay with garbage in / garbage out, > the > management side of me says sometimes you have to expect bad data and try to > make > the best of it - otherwise you lose customers and revenue.
Re: dealing with empty field names in query
On Fri, Feb 13, 2009 at 3:03 PM, Jonathan Vanasco wrote: > A simple typo could render your application broken. Or a hostile competitor.
Re: dealing with empty field names in query
On Feb 13, 2009, at 3:38 PM, André Warnier wrote: The management part of me says that if you sell shoddy merchandise to people, they are going to come back and hit you with it. Presumably, if you get such kind of posted data from a form, it is because you sent a shoddy form to the browser, which can submit such shoddy data. Or because you have some shoddy javascript in the form, which sends shoddy data to your server. So we're still at the garbage level, but the other way around : garbage out, gargabe in. ;-) That's assuming that you're responsible. Today many people use misc javascript libraries; and there are js DMZ servers that serve off cached versions so people don't have to reload. A simple typo could render your application broken.
Re: dealing with empty field names in query
Jonathan Vanasco wrote: On Feb 6, 2009, at 4:58 PM, Phil Carmody wrote: In those name/value pairs, according to HTML 4 at least, the names must begin with a letter [A-Za-z]. The empty string does not do so. Garbage in, garbage out. Part of me agrees with that philosophy. Another part of me is more practical. We had to stop using libapreq2 for cookies, because we found out that wordpress (being a shoddy piece of software) was generating invalid cookies at times. when apreq encountered it, it segfaulted. so while the engineering part of me is okay with garbage in / garbage out, the management side of me says sometimes you have to expect bad data and try to make the best of it - otherwise you lose customers and revenue. The management part of me says that if you sell shoddy merchandise to people, they are going to come back and hit you with it. Presumably, if you get such kind of posted data from a form, it is because you sent a shoddy form to the browser, which can submit such shoddy data. Or because you have some shoddy javascript in the form, which sends shoddy data to your server. So we're still at the garbage level, but the other way around : garbage out, gargabe in. ;-)
Re: Manipulating @INC and tremendous blank page
On Thu, Feb 12, 2009 at 9:55 PM, wrote: > Is there a way to manipulate @INC without having to use a startup.pl in > mod_perl2??? Sure. For example, PERL5LIB. > As for now, I've created a startup.pl to manipulate @INC that is called when > the server is launched > but this has serveral draw backs that i would like to avoid: > - need to hardcode the path in this file (in plain old CGI relative path > were ok) Regarding relative paths, I wouldn't recommend putting your perl libraries inside of DOCUMENT_ROOT if you can avoid it. If you have to use relative paths, you want something like what Mark Hedges suggested. That should work for ModPerl::PerlRun, where your code is compiled every time. For ModPerl::Registry, you'd need to do something like this: use FindBin; unshift @INC, "$FindBin::Bin/../lib"; Unlike "use lib", the unshift will run every time in Registry. Also, if you use RegistryPrefork you won't need FindBin at all. You can just use '../lib'. > I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages > that leaved no log at all. [...] > I have absolutely no clue on how to debug this ?? There are a few things I would try: - Double-check the log file - Add some warn statements to see how far it gets. - Examine the communication with the client through a proxy or Firefox plugin. I think that ModPerl::RegistryPrefork is ultimately where you want to be, because it will be faster. - Perrin
Re: dealing with empty field names in query
On Feb 6, 2009, at 4:58 PM, Phil Carmody wrote: In those name/value pairs, according to HTML 4 at least, the names must begin with a letter [A-Za-z]. The empty string does not do so. Garbage in, garbage out. Part of me agrees with that philosophy. Another part of me is more practical. We had to stop using libapreq2 for cookies, because we found out that wordpress (being a shoddy piece of software) was generating invalid cookies at times. when apreq encountered it, it segfaulted. so while the engineering part of me is okay with garbage in / garbage out, the management side of me says sometimes you have to expect bad data and try to make the best of it - otherwise you lose customers and revenue.
Re: mod_perl2 with mod_dbd and Apache2
On Fri, Feb 13, 2009 at 1:22 PM, Mark Hedges wrote: > Connection pooling is a cool idea but I don't know who's > made it work. I gave a couple of options earlier in this thread. - Perrin
Re: Capturing Apache response
We'll look at pnotes too. Thanks again. -- From: "Mark Hedges" Sent: Friday, February 13, 2009 1:11 PM To: "Solutio at Gmail" Cc: "André Warnier" ; Subject: Re: Capturing Apache response I'm trying to say that you shouldn't use custom headers to save this information, when you should be using the correct facility, which is pnotes. Why do you want to use the wrong thing when the right thing is available? Mark On Fri, 13 Feb 2009, Solutio at Gmail wrote: I understand your point, and we'll strip the custom headers off before sending the response to the client. We are also looking at another way to dump the response (in the application's parent template class), which would help us avoid messing with Apache altogether. -- From: "Mark Hedges" Sent: Friday, February 13, 2009 12:07 PM To: "Solutio at Gmail" Cc: "André Warnier" ; Subject: Re: Capturing Apache response > > > > On Tue, 10 Feb 2009, Solutio at Gmail wrote: > > > First of all, I thank you both for your expert opinion on the topic. > > I > > have > > never had to fiddle with this sort of Apache customization, so I'm > > learning in > > the process... > > > > As for the way to communicate the file name to the filter, sure, we > > would > > like > > to keep it as simple as possible and avoid pitfalls. I agree that > > Perl is > > a > > powerful tool that can easily screw many things up if applied > > carelessly. > > > > I guess if we properly implement the custom header option, it > > shouldn't > > become > > a problem. We'll give it a try. > > To recap, you shouldn't use the custom header, you should > probably use $r->pnotes or maybe $c->pnotes to store the > information from the beginning to be accessed at the end. > This is what the pnotes tables are for. Don't mess with the > headers. Headers are for communicating with the client. > > Mark >
Re: Capturing Apache response
I'm trying to say that you shouldn't use custom headers to save this information, when you should be using the correct facility, which is pnotes. Why do you want to use the wrong thing when the right thing is available? Mark On Fri, 13 Feb 2009, Solutio at Gmail wrote: > I understand your point, and we'll strip the custom headers off before sending > the response to the client. We are also looking at another way to dump the > response (in the application's parent template class), which would help us > avoid messing with Apache altogether. > > -- > From: "Mark Hedges" > Sent: Friday, February 13, 2009 12:07 PM > To: "Solutio at Gmail" > Cc: "André Warnier" ; > Subject: Re: Capturing Apache response > > > > > > > > > On Tue, 10 Feb 2009, Solutio at Gmail wrote: > > > > > First of all, I thank you both for your expert opinion on the topic. I > > > have > > > never had to fiddle with this sort of Apache customization, so I'm > > > learning in > > > the process... > > > > > > As for the way to communicate the file name to the filter, sure, we would > > > like > > > to keep it as simple as possible and avoid pitfalls. I agree that Perl is > > > a > > > powerful tool that can easily screw many things up if applied carelessly. > > > > > > I guess if we properly implement the custom header option, it shouldn't > > > become > > > a problem. We'll give it a try. > > > > To recap, you shouldn't use the custom header, you should > > probably use $r->pnotes or maybe $c->pnotes to store the > > information from the beginning to be accessed at the end. > > This is what the pnotes tables are for. Don't mess with the > > headers. Headers are for communicating with the client. > > > > Mark > > >
Re: Capturing Apache response
I understand your point, and we'll strip the custom headers off before sending the response to the client. We are also looking at another way to dump the response (in the application's parent template class), which would help us avoid messing with Apache altogether. -- From: "Mark Hedges" Sent: Friday, February 13, 2009 12:07 PM To: "Solutio at Gmail" Cc: "André Warnier" ; Subject: Re: Capturing Apache response On Tue, 10 Feb 2009, Solutio at Gmail wrote: First of all, I thank you both for your expert opinion on the topic. I have never had to fiddle with this sort of Apache customization, so I'm learning in the process... As for the way to communicate the file name to the filter, sure, we would like to keep it as simple as possible and avoid pitfalls. I agree that Perl is a powerful tool that can easily screw many things up if applied carelessly. I guess if we properly implement the custom header option, it shouldn't become a problem. We'll give it a try. To recap, you shouldn't use the custom header, you should probably use $r->pnotes or maybe $c->pnotes to store the information from the beginning to be accessed at the end. This is what the pnotes tables are for. Don't mess with the headers. Headers are for communicating with the client. Mark
Re: mod_perl2 with mod_dbd and Apache2
You'd probably want to use Apache::DBI in that case. I got the impression that you were maybe running under a threaded model with many children serving static content but sometimes opening DBI connections. Connection pooling is a cool idea but I don't know who's made it work. For example, `man DBI` says: "Why would you want to do this? You don't, forget I even mentioned it. Unless, that is, you're implementing something advanced like a multi-threaded connection pool. See DBI::Pool." But DBI::Pool doesn't appear to be on CPAN. Probably what you want to do is to factor the parts of your application that require the database onto a separate server with a different URL, that way you can manage them. Mark On Wed, 11 Feb 2009, Ivan Heffner wrote: > I realize that this response is months late, but this thread is only > now coming to my attention due to another recent response. Still, I > think you may have been trying to solve the wrong problem. Perhaps I'm > missing a detail or two here, but you are running mod_perl. Perl > processes live on beyond the time to service one request. Why don't > you set up a PerlChildInitHandler that establishes your database > connection and holds on to it? > > $dbh = DBI->connect_cached($data_source, $username, $password, \%attr) > or die $DBI::errstr; > > As long as you are not running so many severs / children that you > saturate you DB connection limit, you should be fine. > > Ivan > > On Wed, Aug 27, 2008 at 1:15 AM, Timothy Partee wrote: > > > > Quick question for the list. I've been scouring Google looking for > > information on Connection Pooling to MySQL 5.0 in mod_perl2 on Apache2 using > > mod_dbd or similar, and while I can find docs for configuring mod_dbd in > > Apache2, and am quite familiar with mod_perl development, I'm unable to find > > specific examples online for how to code mod_perl to access mod_dbd > > connection pools via APR... Am I completely on the wrong track? Is there > > another more simple way to implement MySQL DBI connection pooling in > > mod_perl? > > I'm running a website that is starting to get enough traffic that opening > > a fresh DB connection via Perl's DBI libs on each request is starting to > > cost me serious time in serving mod_perl pages through Apache2, and I'd like > > to implement connection pooling to improve performance. Any suggestions or > > URLs that could help me get on the right track would be muchly appreciated! > > > > Thanks, > > > > - Tim Partee > > > > >
Re: Manipulating @INC and tremendous blank page
On Fri, 13 Feb 2009, shiriru0...@hotmail.com wrote: > - I was manipulating @INC in a BEGIN block but wasn't working. > The main app index.pl is very basic: > > use strict; > use warnings; > > use App::Core Run => 'App::Engine'; > > I was doing the manip of @INC in the App::Engine module > within a BEGIN block but then move it to the import function of App::Engine, > to > no unvail. Would this work in your CGI instead of fiddling with @INC: use FindBin; use lib "$FindBin::Bin/../lib"; or something like that? Mark
Re: Capturing Apache response
On Tue, 10 Feb 2009, Solutio at Gmail wrote: > First of all, I thank you both for your expert opinion on the topic. I have > never had to fiddle with this sort of Apache customization, so I'm learning in > the process... > > As for the way to communicate the file name to the filter, sure, we would like > to keep it as simple as possible and avoid pitfalls. I agree that Perl is a > powerful tool that can easily screw many things up if applied carelessly. > > I guess if we properly implement the custom header option, it shouldn't become > a problem. We'll give it a try. To recap, you shouldn't use the custom header, you should probably use $r->pnotes or maybe $c->pnotes to store the information from the beginning to be accessed at the end. This is what the pnotes tables are for. Don't mess with the headers. Headers are for communicating with the client. Mark
Re: dynamic caching
On Fri, Feb 13, 2009 at 4:00 AM, wrote: > Can we write a dynamic caching system with modperl within few days? > I got the idea from this article: > > http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ib > m.websphere.iseries.doc/info/ae/ae/welc6tech_dyn.html That's a huge article. Which part sounded good to you? There are many caching tools available for mod_perl. - Perrin
dynamic caching
Hello, Can we write a dynamic caching system with modperl within few days? I got the idea from this article: http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ib m.websphere.iseries.doc/info/ae/ae/welc6tech_dyn.html Any comments are welcome. We can pay for this project if you can do it. Thanks. Regards. **The year's hottest artists on the red carpet at the Grammy Awards. AOL Music takes you there. (http://music.aol.com/grammys?ncid=emlcntusmusi0004)
