Re: FYI
Fred Moyer wrote: > There was a recent sytems upgrade which probably caused this. Looking > into it. Yup, caused by a switch to a 64 bit OS. A couple of CPAN packages need rebuilding, I am taking care of it. Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/ signature.asc Description: OpenPGP digital signature
Re: Finding memory leaks
Chetan Sarva wrote: > Hey all, > > We've got an aging web app running on Apache/1.3.34 (Ubuntu) and > mod_perl/1.29 which we know has several memory leaks --- apache has > been crashing of late and we'd like to stop that. For the time being > we're using Apache::SizeLimit but would like to actually find and fix > the root causes too :) > > So far, the best tool I've found is Devel::Cycle but using it is hit > or miss. I've applied it in some key spots where we know our data > model has a parent-child relationship as well as some generic factory > methods but actually finding circular refs is like a needle in a > haystack. I've found and fixed 2 so far but am almost certain there > are others there, lurking deep in the bowels. > > Are there any better tools or more generic ways to attack this? Have you tried Apache::Leak? http://search.cpan.org/~gozer/mod_perl-1.30/Leak/Leak.pm It's handy when you are running mod_perl-1.x Also, building Perl with -DDEBUG_LEAKING_SCALARS can be very enlightening if you can afford to build your own Perl. Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/ signature.asc Description: OpenPGP digital signature
Re: Rose::DB and Apache::DBI
On 10/23/07, John Siracusa <[EMAIL PROTECTED]> wrote: > My problems were more along the lines of not realizing that an internal > subrequest was happening, which (if memory serves) would end up clearing > pnotes (or maybe my code was clearing/resetting pnotes when re-traversed for > the subrequest). In mod_perl 1, you can only store pnotes at a request level, so a subrequest has separate pnotes. This meant you would need to lookup the parent request ($r->main) to get your pnotes. In mod_perl 2, you have the option of using pnotes on a connection level instead of a request level. I recommend pnotes any time you need to pass data between mod_perl phases or store something that has to be cleared at the end of every request. It's generally more reliable than using globals and manually clearing them in a cleanup handler. - Perrin
Re: Rose::DB and Apache::DBI
On 10/24/07 10:39 AM, Perrin Harkins wrote: > In mod_perl 1, you can only store pnotes at a request level, so a > subrequest has separate pnotes. This meant you would need to lookup > the parent request ($r->main) to get your pnotes. In mod_perl 2, you > have the option of using pnotes on a connection level instead of a > request level. Ah, that explains it. > I recommend pnotes any time you need to pass data between mod_perl > phases or store something that has to be cleared at the end of every > request. It's generally more reliable than using globals and manually > clearing them in a cleanup handler. Well, if we trust register_cleanup() to clean up db connections and so on, why not trust it to reset globals too? That's what I tend to do and it's never let me down. -John
Re: Rose::DB and Apache::DBI
On 10/24/07, John Siracusa <[EMAIL PROTECTED]> wrote: > Well, if we trust register_cleanup() to clean up db connections and so on, > why not trust it to reset globals too? The problems I had involved unpredictable order of execution with multiple cleanups. I'm fuzzy on the details though, since this was like 10 years ago. I'm sure it can be made to work. I found pnotes more foolproof in this case. - Perrin
Re: Finding memory leaks
On Oct 24, 2007, at 3:59 AM, Philippe M. Chiasson wrote: Have you tried Apache::Leak? http://search.cpan.org/~gozer/mod_perl-1.30/Leak/Leak.pm Everything I've read about Apache::Leak says it points out lots of false positives and can be a huge waste of time. Maybe I'll give it a try anyway. I've got time to waste.
mod_perl MVC framework.
Hi List, Hey I was wondering if there was any MVC framework that anybody on this list could point me to that work work well with mod_perl. We are having difficulty finding a good MVC framework for perl. I have looked at HTML::Mason and the template toolkit today. I am not quite sure mason is a MVC framework. The template toolkit looks promising. Tyler
Re: mod_perl MVC framework.
there's a list here: http://perl.apache.org/products/app-server.html Adam Quoting Tyler Bird <[EMAIL PROTECTED]>: Hi List, Hey I was wondering if there was any MVC framework that anybody on this list could point me to that work work well with mod_perl. We are having difficulty finding a good MVC framework for perl. I have looked at HTML::Mason and the template toolkit today. I am not quite sure mason is a MVC framework. The template toolkit looks promising. Tyler
Re: mod_perl MVC framework.
"Tyler Bird" <[EMAIL PROTECTED]> wrote... > Hi List, Hi Tyler, > Hey I was wondering if there was any MVC framework that anybody on this > list could point me to that work work well with mod_perl. > > We are having difficulty finding a good MVC framework for perl. /me points you to -> CGI::Application http://search.cpan.org/search?query=CGI::Application hth, -dav
Re: mod_perl MVC framework.
Hi Tyler > We are having difficulty finding a good MVC framework for perl. > > I have looked at HTML::Mason and the template toolkit today. > I am not quite sure mason is a MVC framework. The template toolkit > looks promising. Neither TT or Mason are MVC frameworks, but they can be used to provide the V(iew) in MVC. What you're looking for is one of the following, in no particular order: Catalyst Jifty CGI::Application CGI::Prototype And even then, you will most likely end up using TT or Mason for the view. regards, Juan Natera
Re: mod_perl MVC framework.
On 24 Oct 2007, at 17:26, Tyler Bird wrote: Hi List, Hey I was wondering if there was any MVC framework that anybody on this list could point me to that work work well with mod_perl. We are having difficulty finding a good MVC framework for perl. I have looked at HTML::Mason and the template toolkit today. I am not quite sure mason is a MVC framework. The template toolkit looks promising. TT is only the view part really, you want Catalyst. trust me. :) http://www.catalystframework.org/ -Mark Tyler
Re: mod_perl MVC framework.
Catalyst is a MVC framework we can use with mod_perl http://www.catalystframework.org/ On 10/24/07, Tyler Bird <[EMAIL PROTECTED]> wrote: > Hi List, > > Hey I was wondering if there was any MVC framework that anybody on this > list could point > me to that work work well with mod_perl. > > We are having difficulty finding a good MVC framework for perl. > > I have looked at HTML::Mason and the template toolkit today. > I am not quite sure mason is a MVC framework. The template toolkit > looks promising. > > Tyler >
Re: Finding memory leaks
The following always works for me: Run apache2(pre fork) with '-X' option under valgrind: In my system it looks something like this: valgrind --leak-check=full /usr/sbin/apache2 -X If you are using any 'XS' based perl modules, it would show memory leaks/errors, if any in any of the loaded shared libs. On 10/24/07, Chetan Sarva <[EMAIL PROTECTED]> wrote: > > > On Oct 24, 2007, at 3:59 AM, Philippe M. Chiasson wrote: > > > Have you tried Apache::Leak? > > > > http://search.cpan.org/~gozer/mod_perl-1.30/Leak/Leak.pm > > Everything I've read about Apache::Leak says it points out lots of > false positives and can be a huge waste of time. Maybe I'll give it a > try anyway. I've got time to waste. >
SCRIPT_NAME & PATH_INFO %ENV variables
judging by this thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15609.html This might be an old question but I'm not entirely sure I understand the answer spelled out in the response. I have the following Location setting in my httpd.conf (via an include file): SetHandler perl-script PerlResponseHandler mod_perl::Test hits to various related urls result in the following: http://localhost/mod_perl/ SCRIPT_NAME = /mod_perl PATH_INFO = / http://localhost/mod_perl/test1 SCRIPT_NAME = /mod_perl PATH_INFO = /test1 http://localhost/mod_perl/test1/test2 SCRIPT_NAME = /mod_perl PATH_INFO = /test1/test2 when using CGI.pm and the url(relative => 1) method, always results in 'mod_perl', as opposed to the basename (for lack of a better word) in SCRIPT_NAME. Is there any way to get have the url() method get the SCRIPT_NAME defined by the regex: s|/.*/(.*)|$1| (that may not account for all possibilities, but close enough for an example) Thanks, -lev
DirectoryIndex
Hello, I'm running modperl2 on Debian from the libapache2-mod-perl2 debian package and I can't get the DirectoryIndex rule to work properly. I have the line DirectoryIndex index.html index.cgi index.pl index.php index.xhtml in apache2.conf, and in the file default in sites-available... nether seem to have any effect as I get the error: "Attempt to serve directory:" . correct doc root. I have found this post http://www.wlug.org.nz/SargeApache2Notes that explains that this is a "bug" and directs me to a dead blog. Does anyone out there know a work around or a fix that has worked for you? Thanks so much! Marilyn
Re: SCRIPT_NAME & PATH_INFO %ENV variables
On Wed, 24 Oct 2007, Lev Lvovsky wrote: judging by this thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15609.html This might be an old question but I'm not entirely sure I understand the answer spelled out in the response. I have the following Location setting in my httpd.conf (via an include file): SetHandler perl-script PerlResponseHandler mod_perl::Test hits to various related urls result in the following: http://localhost/mod_perl/ SCRIPT_NAME = /mod_perl PATH_INFO = / http://localhost/mod_perl/test1 SCRIPT_NAME = /mod_perl PATH_INFO = /test1 http://localhost/mod_perl/test1/test2 SCRIPT_NAME = /mod_perl PATH_INFO = /test1/test2 when using CGI.pm and the url(relative => 1) method, always results in 'mod_perl', as opposed to the basename (for lack of a better word) in SCRIPT_NAME. Is there any way to get have the url() method get the SCRIPT_NAME defined by the regex: s|/.*/(.*)|$1| (that may not account for all possibilities, but close enough for an example) The code in CGI::Apache2::Wrapper: http://cpan.uwinnipeg.ca/htdocs/CGI-Apache2-Wrapper/CGI/Apache2/Wrapper.pm.html#Apache2_URI provides a CGI-compatible url() method based on Apache2::URI: http://cpan.uwinnipeg.ca/htdocs/mod_perl/Apache2/URI.html -- best regards, Randy Kobes
Re: SCRIPT_NAME & PATH_INFO %ENV variables
On Oct 24, 2007, at 4:31 PM, Randy Kobes wrote: The code in CGI::Apache2::Wrapper: http://cpan.uwinnipeg.ca/htdocs/CGI-Apache2-Wrapper/CGI/Apache2/ Wrapper.pm.html#Apache2_URI provides a CGI-compatible url() method based on Apache2::URI: http://cpan.uwinnipeg.ca/htdocs/mod_perl/Apache2/URI.html Hi Randy, thanks for the reference. Is there no other way to get these same results via the CGI.pm package? I would be a lot more eager to use the Wrapper package if there was some sort of explanation as to why CGI.pm doesn't work in it's current state - we're using the CGI package in a lot of our code, and I'm not sure that the Wrapper package has all of the backwards compatibility that we need. thanks! -lev
Re: DirectoryIndex
Marilyn Burgess wrote: > Hello, > > I'm running modperl2 on Debian from the libapache2-mod-perl2 debian package > and I can't get the DirectoryIndex rule to work properly. I have the line > > DirectoryIndex index.html index.cgi index.pl index.php index.xhtml > > in apache2.conf, and in the file default in sites-available... nether seem > to have any effect as I get the error: "Attempt to serve directory:" . > correct doc root. > > I have found this post http://www.wlug.org.nz/SargeApache2Notes that > explains that this is a "bug" and directs me to a dead blog. Does anyone out > there know a work around or a fix that has worked for you? that site links to a broken mail list archive, so you could search other public archives around that time for the same thread. or, of course, google is your friend :) you may find this helpful: http://marc.info/?l=apache-modperl&m=112808685415719&w=2 --Geoff
Re: mod_perl MVC framework.
What is fast to cook, good to eat is HTML::Template. No XML, easy abstraction between your web designer and developer. Tyler Bird wrote: Hi List, Hey I was wondering if there was any MVC framework that anybody on this list could point me to that work work well with mod_perl. We are having difficulty finding a good MVC framework for perl. I have looked at HTML::Mason and the template toolkit today. I am not quite sure mason is a MVC framework. The template toolkit looks promising. Tyler
Re: SCRIPT_NAME & PATH_INFO %ENV variables
On Wed, 24 Oct 2007, Lev Lvovsky wrote: On Oct 24, 2007, at 4:31 PM, Randy Kobes wrote: The code in CGI::Apache2::Wrapper: http://cpan.uwinnipeg.ca/htdocs/CGI-Apache2-Wrapper/CGI/Apache2/Wrapper.pm.html#Apache2_URI provides a CGI-compatible url() method based on Apache2::URI: http://cpan.uwinnipeg.ca/htdocs/mod_perl/Apache2/URI.html Hi Randy, thanks for the reference. Is there no other way to get these same results via the CGI.pm package? I would be a lot more eager to use the Wrapper package if there was some sort of explanation as to why CGI.pm doesn't work in it's current state - we're using the CGI package in a lot of our code, and I'm not sure that the Wrapper package has all of the backwards compatibility that we need. I misunderstood your question - I thought you were trying to do this just under mod_perl, without CGI.pm. The CGI::Apache2::Wrapper package and CGI.pm are intended to give the same results, assuming the tests pass: http://search.cpan.org/src/RKOBES/CGI-Apache2-Wrapper-0.21/t/response/TestCGI/misc.pm If none of the CGI.pm options to url() give what you need, you may want to ask the author of CGI.pm, Lincoln Stein, about the background for the present behavior. -- best regards, Randy
Re: SCRIPT_NAME & PATH_INFO %ENV variables
On Oct 24, 2007, at 9:01 PM, Randy Kobes wrote: I misunderstood your question - I thought you were trying to do this just under mod_perl, without CGI.pm. The CGI::Apache2::Wrapper package and CGI.pm are intended to give the same results, assuming the tests pass: http://search.cpan.org/src/RKOBES/CGI-Apache2-Wrapper-0.21/t/ response/TestCGI/misc.pm If none of the CGI.pm options to url() give what you need, you may want to ask the author of CGI.pm, Lincoln Stein, about the background for the present behavior. -- best regards, Randy Thanks for your help Randy, I installed your package, and as you stated, it gives the same results as CGI.pm, which from the looks of it seem to make sense - I'll getting clarification on the "problem". Thanks again, -lev
