Re: Trouble Compiling Mod_Perl 1.27 on SGI
Hi there, On Mon, 14 Oct 2002, Kent, Mr. John wrote: Having trouble building mod_perl-1.27 against Apache_1.3.27 on an SGI Have you looked at the file mod_perl-1.27/SUPPORT ? Did you build the Perl installation on these machines? Could you use a different compiler? 73, Ged.
ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello, I have a mod_perl application which does a internal_redirect() and registers a cleanup handler before returning. I am noticing that the cleanup handler executes and i see the following in my log .. [Tue Oct 15 03:27:32 2002] [info] [client XYZ ] (9)Bad file number: client stopped connection before rvputs completed * Why is apache trying to write to client during the cleanup phase ? Further ... Since the call is to ap_rvputs(), I assumed it is not a mod_perl issue. I confirmed that the handler was 'default-handler' by asking ap_invoke_handler() to log each invocation. But when I forced the handler to be 'perl-script' by using internal_redirect_handler(). This time I get [Tue Oct 15 00:59:29 2002] [info] [client XYZ] (9)Bad file number: client stopped connection before rwrite completed I hacked ap_rvputs() ap_rwrite() to not return on a write() failure but to log the attempt. It seems that both want to write HTTP headers to client. ( I confirmed that it is for the same request 'r-the_request') Why is apache re-doing the request after a internal_redirect() ? ( and that too in the cleanup phase ??) Please help me understand this. Any hints most appreciated :-) regards srp ps :: please reply to me directly as i am not on the list
Can I parse content that has been returned to user by simple cgi script?
Hello! I want to upgrade my project with implementing some feature. Project was writen for mod_cgi, but I would like to parse content that was generated by my scripts to implement something like SSI or Apache::UCase and etc. I don't know how to set stacked handler after mod_cgi. May be it's wrong way of doing this? Could I do this? Beforehand thank. _ Sorry for my bad English. mailto:[EMAIL PROTECTED]
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. That from Writing Apache modules with Perl and C. ssn Hello, ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED]
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Hello again. May be it helps to solve your problem. is_initial_req() There are several instances in which an incoming URI request can trigger one or more secondary internal requests. An internal request is triggered when internal_redirect() is called explicitly, and it also happens behind the scenes when lookup_file() and lookup_uri() are called. With the exception of the logging phase, which is run just once for the primary request, secondary requests are run through each of the transaction processing phases, and the appropriate handlers are called each time. There may be times when you don't want a particular handler running on a subrequest or internal redirect, either to avoid performance overhead or to avoid infinite recursion. The is_initial_req() method will return a true value if the current request is the primary one and false if the request is the result of a subrequest or an internal redirect. return DECLINED unless $r-is_initial_req; ssn Hello, ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED]
Re: ap_rwrite()/ap_rvputs() called in PerlCleanupHandler
Thanks for reply .. Hello! internal_redirect() The required argument is an absolute URI path on the current server. The server will process the URI as if it were a whole new request, running the URI translation, MIME type checking, and other phases before invoking the appropriate content handler for the new URI. The content handler that eventually runs is not necessarily the same as the one that invoked internal_redirect(). This method should only be called within a content handler. Yes, I understand that. What I am saying is this ... After a successfull internal_redirect(), and return OK my content handler has exited - The content has now reached my client. Now my cleanup handler is executing. I am not understanding why Apache is attempting to write to client now !! Also, by using internal_redirect_handler() you can make r-handler (which is the current handler by default) handle this redirect(). ssn Why is apache re-doing the request after a internal_redirect() ? ( and that too ssn in the cleanup phase ??) ssn Please help me understand this. Any hints most appreciated :-) mailto:[EMAIL PROTECTED] regards srp
[mp2] segfault deleting ENV variable
The following one line script will cause apache/mod_perl2 to segfault:
delete ::ENV{'PATH'};
I've tried this with both apache-2.0.40/mod_perl-1.99_05/perl-5.8.0 (ie
stock RH8), and apache-2.0.43/mod_perl-1.99_07/perl-5.8.0
A backtrace from the later combination gives:
#0 0x4024b447 in Perl_mg_clear ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#1 0x40253989 in Perl_hv_delete_ent ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#2 0x4027ff27 in Perl_pp_delete ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#3 0x40258059 in Perl_runops_standard ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#4 0x40200139 in S_call_body ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#5 0x401ffeb6 in Perl_call_sv ()
from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so
#6 0x401c85f2 in modperl_callback ()
from /usr/local/apache2/modules/mod_perl.so
#7 0x401c8abe in modperl_callback_run_handlers ()
from /usr/local/apache2/modules/mod_perl.so
#8 0x401c8d05 in modperl_callback_per_dir ()
from /usr/local/apache2/modules/mod_perl.so
#9 0x401c4a55 in modperl_response_handler_run ()
from /usr/local/apache2/modules/mod_perl.so
#10 0x401c4c75 in modperl_response_handler_cgi ()
from /usr/local/apache2/modules/mod_perl.so
#11 0x0807c4f0 in ap_run_handler (r=0x8160178) at config.c:195
#12 0x0807cad6 in ap_invoke_handler (r=0x8160178) at config.c:401
#13 0x0806afc7 in ap_process_request (r=0x8160178) at http_request.c:288
#14 0x08066be1 in ap_process_http_connection (c=0x815bd10) at
http_core.c:293
#15 0x08086268 in ap_run_process_connection (c=0x815bd10) at
connection.c:85
#16 0x08086555 in ap_process_connection (c=0x815bd10, csd=0x815bc40)
at connection.c:207
#17 0x0807ae0d in child_main (child_num_arg=1651076143) at prefork.c:696
#18 0x0807afd4 in make_child (s=0x80b9358, slot=0) at prefork.c:736
#19 0x0807b041 in startup_children (number_to_start=5) at prefork.c:808
#20 0x0807b7bf in ap_mpm_run (_pconf=0x80ab53c, plog=0x80eed30,
s=0x80b9358)
at prefork.c:1024
#21 0x08080d8e in main (argc=2, argv=0xb924) at main.c:643
#22 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
I built apache with debug info, but forgot to build mod_perl that way. The
above one liner script should be enough to reproduce this, though.
This happens in PerlRun or Registry mode. It isn't restricted to the PATH
variable; deleting any existing ENV var causes the crash.
Thanks,
Bradley
mod_perl Guide Patch
Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hope that helps lee
Re: mod_perl Guide Patch
At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? -- Per Einar Ellefsen [EMAIL PROTECTED]
mod_perl history
Hello mod_perlers, I have been working on a document retracing mod_perl's history for a while. While it's not finished yet, I have decided to put it online so that you can all have a look at it and contribute additions which are sorely needed. It currently only deals with mod_perl 1.x, as well as related events. You can find it at: http://perl.apache.org/about/history.html If you have something to contribute, please send it to me directly or to the docs-dev list. Everything in relation to mod_perl, Perl or Apache is welcome, such as the appearance of important modules, new major releases of Perl or Apache, or the items listed in the META list, to name a few examples. As well as 2.0 information, of course. Your faithful historian, -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. Thanks for your advice, I am thinking besides the general advice I have received, Apache::DB will be my next most helpfull item. Eric At 02:33 PM 10/14/02 -0400, William McKee wrote: On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I had to read that over a few times to get it. And now I see that I do indeed have that situation, there are a number of times when I call my $holdstatus = new Holds(); from within a module that also has a new method. What I don't understand is how does my code work at all? Thanks, Eric At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote: On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED] (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: CGI parameters appear to be doubled on 8 bit chars...
* Rob Mueller [EMAIL PROTECTED] [2002-10-13 08:00]:
Just wondering if anyone has seen this problem before, or has a general
solution to it. Basically what we see, is that with some submitted forms,
usually with 8 bit data, the POST parameters passed become 'doubled'. The
problem is that we have a loop like this to gather out all the parameters
early on in our handler code.
This isn't a solution, but you could unique the values:
foreach my $Key ($R-param) {
my %uniq;
my @UParam = grep { ++$uniq{$_} == 1 } $R-param($Key);
$CGIState{$Key} = scalar(@UParam) 1 ? \@UParam : $UParam[0];
}
(darren)
--
You can discover more about a person in an hour of play than in a year
of discussion.
-- Plato
Re: Apache Hello World Benchmarks Updated
Dave Rolsky wrote: On Mon, 14 Oct 2002, Josh Chamas wrote: This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. FYI, I reposted the benchmarks without the MaxRequestsPerChild 100 set for HTML::Mason Template Toolkit, as it was only Embperl 2.x that needed it. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Can I parse content that has been returned to user by simplecgi script?
Ruslan U. Zakirov wrote: I want to upgrade my project with implementing some feature. Project was writen for mod_cgi, but I would like to parse content that was generated by my scripts to implement something like SSI or Apache::UCase and etc. You can't do that. However, you can run your CGI scripts under Apache::PerlRun and then use Apache::Filter on them to do things like SSI. This will also make them much faster. - Perrin
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 15 Oct 2002 at 7:12, Eric Frazier wrote: I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. That sounds like trouble. The only problem I've had running httpd -X is when I compiled mod_ssl into my server. Apparently, it doesn't like to run in single processor mode (although I haven't confirmed this). Otherwise, the single processor mode should work just like multi-processor. I'd start looking into the code that checks that status. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
Re: Apache Hello World Benchmarks Updated
Ed wrote: Hi, (as far as i can tell after a quick peek at the code and some debugging) It looks like there is a bug w/ AxKit::run_axkit_engine() and/or Apache::AxKit::Cache::_get_stats() This is really great Ed. Adding the AxGzipOutput On config to the XSLT tests in the benchmark does seem to correctly activate the cache layer, and AxKit now dominates in speed on the larger XSLT transformation! I will leave off the config for the XSP tests since it does not seem to help at all there. I will republish benchmarks with the new configs soon, thanks so much for digging into this. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
current state of conf/code, feedback?
Hi all
I'm asking for some insight, guidance, comments from the list.
I'm currently running a pilot appunder win2000 + apache 2.0.42 + perl5.8 + mod_perl. Mostly, it's running great, much faster than the vanilla CGI version. I think the database connection is slowing it down though... I currently have CGI pages caching on the client side, which is helping some, but I'm also going to experiment with CGI::Cache.
The application uptime is 2 weeks, but that's includingprayers.
Here are the specifics.
In the http.conf, I have:
LoadFile "C:/Perl/bin/perl58.dll"LoadModule perl_module modules/mod_perl.soPerlRequire "C:/Apache2/conf/startup.pl"PerlInterpStart 5PerlInterpMaxSpare 5PerlInterpMax 20PerlInterpMaxRequests 5
In an included snoopy.conf:
Alias /snoopy/ "C:/Apache2/application/snoopy2/"Location "/snoopy/" ExpiresActive On ExpiresDefault "now plus2 days" SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI/Location
In the startup.pl:
#!C:/Perl/bin/Perl.exeuse Apache2();use ModPerl::Registry ();use DBI;use DBD::ODBC;use HTML::Template;1;
I'm running the app under ModPerl::Registry (evident enough). The bulk of it is in Snoopy.pm, which Iimplement via OO method calls. Currently, each of 5 cgi pageshas ause Snoopy.pm at the top.
The beginning of Snoopy.pm, before the actual methods,looks like:
# Since each CGI page has use Snoopy.pm, I put these directives at the top of# Snoopy module.I thought itmight be more efficient to have them in one place, # instead ofrepeating them in each of the 5 CGI pages.use CGI::Lite;use HTTP::Date;use DBI;use HTML::Template;use HTML::Parser;
package Snoopy;use strict;
#--# Class Data#--###connect to ODBC-ORACLE my $db = ''; my $user = ''; my $pass = ''; my $DBH = DBI-connect("DBI:ODBC:$db", $user, $pass, { RaiseError = 1, PrintError = 1, AutoCommit = 1 }) or die( "Unable to connect to Database: $DBI::errstr\n" ) ; $DBH-{LongReadLen} = 1;
our $AUTOLOAD;
### Set the tracing level to 2 and prepare #DBI-trace( 1, 'dbitrace2.log' ); #--sub new{ my ($class, @args) = @_; my $obj = {};
# Bless the hash reference obj. Create an object. bless $obj, $class; $obj-{dbh} = \$DBH; # Call _init $obj-_init(@args);
# return Object. return $obj;}
methods ...
1;
Is there anything here that spells trouble? What kind of troubleis therefor having use DBI and use HTML::Templatein bothstartup.pl and Snoopy.pm (besides being redundant)?Since Snoopy.pm is the meat and pototoes, should it also be in startup.pl? Does declaring Class variables, such as the DBI handle, offer any benefits (or pain)of a shared connection?
Are there anyobvious (or not soobvious)issues with these configurations or codethatshould be knocking me in the head?
Thanks,Paul
Re: current state of conf/code, feedback?
On Tue, 15 Oct 2002, Paul Simon wrote: variables, such as the DBI handle, offer any benefits (or pain) of a shared connection? You might want to try using Apache::DBI for persistent connections. It is completely transparent to your code, in terms of changes. R. -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI for persistent connections
I was under the impression that Apache::DBI isn't compatible for this set up: win2000 + apache2.0.42 + perl5.8 + mod_perl1.99 For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI. Rafiq Ismail [EMAIL PROTECTED] wrote: On Tue, 15 Oct 2002, Paul Simon wrote: variables, such as the DBI handle, offer any benefits (or pain) of a shared connection?You might want to try using Apache::DBI for persistent connections.It is completely transparent to your code, in terms of changes.R.-- Senior ProgrammerBookings.nl--Me::[EMAIL PROTECTED]||www.dreamthought.comBudget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI for persistent connections
Paul Simon wrote: I was under the impression that Apache::DBI isn't compatible for this set up: win2000 + apache2.0.42 + perl5.8 + mod_perl1.99 For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI. Apache::DBIPool doesn't actually exist yet. Apache::DBI will work correctly in a threaded environment if your DBD is thread-safe. Remember, no variables are shared between Perl threads unless you explicitly share them. - Perrin
Re: current state of conf/code, feedback?
Hi there, On Tue, 15 Oct 2002, Paul Simon wrote: I'm currently running a pilot app under win2000 + apache 2.0.42 + perl5.8 + mod_perl. Is there anything here that spells trouble? That win...thing? Seriously though, you're using very new software. If you want real stability I'd suggest Linux and versions 1.x of mod_perl and Apache might be a shade more reliable at present. But if you are happy with a couple of weeks of uptime (I like to measure it in years...:) then you should be fine with what you're using. 73, Ged. PS: Which bike got wrecked?
Is there an easy way to trace / debug Apache::DBI (Postgres) leaks?
I'm using Apache::DBI connecting to a Postgres db. I'm using Template
Toolkit but no explicit db calls from within the templates -- they're all
done within the perl modules.
Unfortunately after a couple of hours of moderate use Postgres reaches its
max_clients level (which is set below max httpds in httpd.conf) and apache
has to be graceful'd to restore the situation. At this point there's no
work being done, so presumably the handles aren't being freed. I've made
sure that all db calls are fully read, e.g. doing while ($sth-fetch) {..}
routines on all selects so as to avoid leaving results unread.
Does anyone have any tips on how to, at this point, go about detecting
where the handle leak might be (which I'm presuming is the problem)? Or
should Template::Toolkit be avoided altogether when using mod_perl and
database connectivity? I'm using a 1.3 setup.
Cheers
Re: current state of conf/code, feedback?
I have no choice about the win thing. I'd feel much happier using linux and mod_perl 1.x as you suggest. I'm terribly frightenedaboutonly having2 weeks of uptime -that's what the prayings for :) But I'm putting my faith in this very new software and the wonderful people who have been cultivating and supporting it. I wrecked that bike on my home from the universitysome years ago... It was my first and last motorcycle. Thanks for the feedback,Paul Ged Haywood [EMAIL PROTECTED] wrote: Hi there,On Tue, 15 Oct 2002, Paul Simon wrote: I'm currently running a pilot app under win2000 + apache 2.0.42 + perl5.8 + mod_perl. Is there anything here that spells trouble?That win...thing?Seriously though, you're using very new software. If you want realstability I'd suggest Linux and versions 1.x of mod_perl and Apachemight be a shade more reliable at present. But if you are happy witha couple of weeks of uptime (I like to measure it in years...:) thenyou should be fine with what you're using.73,Ged.PS: Which bike got wrecked?
Re: current state of conf/code, feedback?
Paul Simon wrote: I currently have CGI pages caching on the client side, which is helping some, but I'm also going to experiment with CGI::Cache. There are some mod_perl specific version of this too, like the one from the mod_perl Developer's Cookbook (Apache::CacheContent), but these are mod_perl 1.x and probably require work to get them running on mod_perl 2. Traditionally this has mostly been done with a caching reverse proxy, and that's another angle you could try. What kind of trouble is there for having use DBI and use HTML::Template in both startup.pl and Snoopy.pm (besides being redundant)? None. That is the right thing to do, because it preloads the modules (by having them in startup.pl) and documents the dependencies (by putting in Snoopy.pm). Since Snoopy.pm is the meat and pototoes, should it also be in startup.pl? Yes. Does declaring Class variables, such as the DBI handle, offer any benefits (or pain) of a shared connection? You're getting yourself into major trouble there. You should use Apache::DBI instead. The way you have it now (with the connection code in the main section of Snoopy.pm), that database connection will be created when you use the module in startup.pl. Apache will then fork and multiple children will try to share the same $DBH. Disaster. Also, your solution will not try to reconnect if it loses its connection. Apache::DBI will. And you are creating a closure here with your $DBH which might come back to bite you later if your module gets automatically reloaded when you change it. - Perrin
Re: Is there an easy way to trace / debug Apache::DBI (Postgres) leaks?
.--[ Kirk Bowe wrote (2002/10/15 at 20:40:15) ]--
|
| I'm using Apache::DBI connecting to a Postgres db. I'm using Template
| Toolkit but no explicit db calls from within the templates -- they're all
| done within the perl modules.
|
| Unfortunately after a couple of hours of moderate use Postgres reaches its
| max_clients level (which is set below max httpds in httpd.conf) and apache
| has to be graceful'd to restore the situation. At this point there's no
| work being done, so presumably the handles aren't being freed. I've made
| sure that all db calls are fully read, e.g. doing while ($sth-fetch) {..}
| routines on all selects so as to avoid leaving results unread.
|
| Does anyone have any tips on how to, at this point, go about detecting
| where the handle leak might be (which I'm presuming is the problem)? Or
| should Template::Toolkit be avoided altogether when using mod_perl and
| database connectivity? I'm using a 1.3 setup.
|
`-
According to the Apache::DBI readme it seems that each apache child
will need one connection to the database, and the child will resuse
that connection for each request.
Have you turned on debugging in Apache::DBI and watched your Apache
error_log for any weirdness?
-
Frank Wiles [EMAIL PROTECTED]
http://frank.wiles.org
-
SafeCWD Status
Whats the staus of the cwd and SafeThread? Will it work with a threaded MPM in Apache 2 yet and safely change to the working directory of the perl script (safecwd). -Joshua Bernstein Systems Administrator University of Arizona
Re: current state of conf/code, feedback?
I'm going to change the DBH code. I've witnessed a few problemsso far where the DBHhas crapped out. I'll try Apache::DBI. I've been wrapping my head around thereverse proxy cache, I have it set up on my home servers.It seems to be a really good solutionfor caching, but it'sfurther down the road for me... In the meantime, I'm going to try the CGI::Cache. Got some work to do :) Thanks for the tips and explanations,Paul Perrin Harkins [EMAIL PROTECTED] wrote: Paul Simon wrote: I currently have CGI pages caching on the client side, which is helping some, but I'm also going to experiment with CGI::Cache. There are some mod_perl specific version of this too, like the one from the mod_perl Developer's Cookbook (Apache::CacheContent), but these are mod_perl 1.x and probably require work to get them running on mod_perl 2. Traditionally this has mostly been done with a caching reverse proxy, and that's another angle you could try. What kind of trouble is there for having use DBI and use HTML::Template in both startup.pl and Snoopy.pm (besides being redundant)?None. That is the right thing to do, because it preloads the modules (by having them in startup.pl) and documents the dependencies (by putting in Snoopy.pm). Since Snoopy.pm is the meat and pototoes, should it also be in startup.pl?Yes. Does declaring Class variables, such as the DBI handle, offer any benefits (or pain) of a shared connection? You're getting yourself into major trouble there. You should use Apache::DBI instead. The way you have it now (with the connection code in the "main" section of Snoopy.pm), that database connection will be created when you use the module in startup.pl. Apache will then fork and multiple children will try to share the same $DBH. Disaster.Also, your solution will not try to reconnect if it loses its connection. Apache::DBI will. And you are creating a closure here with your $DBH which might come back to bite you later if your module gets automatically reloaded when you change it.- Perrin
Re: Is there an easy way to trace / debug Apache::DBI (Postgres)leaks?
Kirk Bowe wrote: Unfortunately after a couple of hours of moderate use Postgres reaches its max_clients level (which is set below max httpds in httpd.conf) This is usually caused by mistakes in your connection calls where they have slightly different connect info resulting in multiple connections. At this point there's no work being done, so presumably the handles aren't being freed. Database handles are not supposed to be freed. That's the point of Apache::DBI. However, you should only have one per httpd process. Does anyone have any tips on how to, at this point, go about detecting where the handle leak might be (which I'm presuming is the problem)? http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_Apache__DBI should Template::Toolkit be avoided altogether when using mod_perl and database connectivity? TT is not related to this. It works great with mod_perl. - Perrin
Apache Hello World Benchmarks: AxKit config fixed XSLT, Cocoon benchmarksadded, Tomcat updated to 4.1.12
Hey, I updated the Apache Hello World Benchmarks with some major updates: AxKit config fixed XSLT performance Cocoon XSLT benchmarks added Tomcat updated to 4.1.12 Check them out at http://chamas.com/bench/ Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Finding a memory leak
I'm dealing with a large code base here and I'm hoping to find out what is being loaded into memory to make an Apache child jump from 25mb to 145mb (interestingly it seems to only affect one every now and then rather than the whole pool) in about 10 seconds. Is there a way to have Apache dump it's memory, or a better way to find out what is causing the problem? Thanks, Ben Davis
Re: mod_perl history
I just had a look at the historical doc. and its great. Provides a good overview on this great open source project. And I hope more will be added. Alfred Vahau Uni. PNG Per Einar Ellefsen wrote: Hello mod_perlers, I have been working on a document retracing mod_perl's history for a while. While it's not finished yet, I have decided to put it online so that you can all have a look at it and contribute additions which are sorely needed. It currently only deals with mod_perl 1.x, as well as related events. You can find it at: http://perl.apache.org/about/history.html If you have something to contribute, please send it to me directly or to the docs-dev list. Everything in relation to mod_perl, Perl or Apache is welcome, such as the appearance of important modules, new major releases of Perl or Apache, or the items listed in the META list, to name a few examples. As well as 2.0 information, of course. Your faithful historian, -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache Hello World Benchmarks Updated
FYI, I reposted the benchmarks without the MaxRequestsPerChild 100 set for HTML::Mason Template Toolkit, as it was only Embperl 2.x that needed it. Embperl 2.0b8 has still some real memory leaks. That's why it called beta. Of course they will be fixed before the final release of 2.0. 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 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
