Re: current state of conf/code, feedback?
Paul Simon wrote: > I was cruising with Apache::DBI, definitely better than the way I had > it, but now suddenly I'm getting this error: > > DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not > current thread b0f18c (handles can't be shared between threads and your > driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm > line 64. > > What's going on? You'd be better off asking on the DBI list, but it looks to me like your DBD is not thread-safe, or else you opened a connection before the fork (in startup.pl). - Perrin
Re: current state of conf/code, feedback?
I was cruising with Apache::DBI, definitely better than the way I had it, but now suddenly I'm getting this error: DBD::ODBC::dr FETCH failed: handle 1 is owned by thread 1e90bdc not current thread b0f18c (handles can't be shared between threads and your driver may need a CLONE method added) at C:/Perl/site/lib/Apache/DBI.pm line 64. What's going on? 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: current state of conf/code, feedback?
I'm going to change the DBH code. I've witnessed a few problems so far where the DBH has crapped out. I'll try Apache::DBI. I've been wrapping my head around the reverse proxy cache, I have it set up on my home servers. It seems to be a really good solution for caching, but it's further 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: 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: 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 frightened about only having 2 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 university some 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?
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?
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]
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 app under 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 including prayers.
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/" ExpiresActive On ExpiresDefault "now plus 2 days" SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI
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 I implement via OO method calls. Currently, each of 5 cgi pages has a use 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 it might be more efficient to have them in one place, # instead of repeating 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 trouble is there for having use DBI and use HTML::Template in both startup.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 any obvious (or not so obvious) issues with these configurations or code that should be knocking me in the head?
Thanks,Paul
