You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jordan Lederman <jl...@advance.net> on 2003/11/21 19:26:17 UTC
mod_perl + DBI + TT2 giving odd results
First off, let me say hi all and thanks for mod_perl as it was just what I was looking for
when starting out this project. The project is an web-based groupware email system which runs as
a mod_perl module on apache 1.3.28. Under normal conditions while I'm testing, everything works
great. It's fast and stable. However, It seems that if I hit reload quickly while I'm in the state where
my app draws the main message list, I get spurious results. Now this doesn't happen everytime that
I hit reload before the page is 'done' and received by me, but most. It seems to correlate with the
(32)Broken pipe: client stopped connection before rwrite completed message below. I'm using Apache::DBI to handle
my db connections ( as well as DBD::Pg and postgresql 7.3.4) and what 'feels' like is happening is that
when I request the url it begins to run the normal and appropriate queries. When i hit reload before the queries
are done, it seems that the query from 2706 - 2710 gets a value that should have been retrieved in the query on
2720/2727 ... often the value of $page_links{numtotal} is 'someguy' which is a value found in the u.name field of the
other query below. Has anyone run into this before? Have any good ideas for me?
--jordan
2704 my @row;
2705 my $sth;
2706 my $count_query = "SELECT count(eid) from queue_${queuename}_email";
2707 $r->warn("[message] ($ENV{REMOTE_ADDR}) Running query $count_query" ) if $debug;
2708 $sth = $dbh->prepare($count_query);
2709 unless ($sth->execute) {return fail($r,SERVER_ERROR,$template->error()); }
2710 $page_links{numtotal} = $sth->fetchrow;
2711
2712 my $unread_query = "SELECT count(eid) from queue_${queuename}_email WHERE date_read IS NULL";
2713 $r->warn("[message] ($ENV{REMOTE_ADDR}) Running query $unread_query" ) if $debug;
2714 $sth = $dbh->prepare($unread_query);
2715 unless ($sth->execute) {return fail($r,SERVER_ERROR,$template->error()); }
2716 $page_links{numunread} = $sth->fetchrow;
2717
2718 my @messagelist;
2719
2720 my $message_query = "SELECT e.eid, e.sender, e.subject, e.level, e.date_read, e.locked, e.hasattach, e.hasnote, e.assigned_to, to_char(t.stamp,'FMMM/FMDD/FMYY HH24:MI'), u.name FROM queue_${queuename}_timestamp t, queue_${queuename}_email e LEFT JOIN users u ON e.assigned_to = u.uid WHERE e.eid = t.eid ORDER BY $sort $limitclause";
2721
2722 $r->warn(" ($ENV{REMOTE_ADDR}) Running query $message_query" ) if $debug;
2723
2724
2725 my $time_before = time() - $start_time;
2726 $sth = $dbh->prepare($message_query);
2727 my $rows = $sth->execute;
2728 my $time_after = time() - $start_time;
2729 $page_links{numend} = $page_links{numstart} + $rows ;
2730 $page_links{numend}--;
2731 while ( @row = $sth->fetchrow_array) {
2732
2733 my $message = {
2734 'eid' => $row[0],
2735 'sender' => clean_sender($row[1]),
2736 'subject' => $row[2],
2737 'level' => $row[3],
2738 'new' => $row[4],
2739 'locked' => islocked($cookie,$row[0]),
2740 'attach' => $row[6],
2741 'note' => $row[7],
2742 'assignedto' => $row[10],
2743 'date' => $row[9],
2744 'link' => $q2_baseurl . 'view/' . $row[0],
2745 'color' => $color{n2w($row[3])}
2746 };
2747 if ( defined($message->{'new'}) ) { $message->{'new'} = 0 } else { $message->{'new'} = 1 }
2748 $message->{'subject'} = 'no subject' unless ($message->{'subject'});
2749 if ( length($message->{'subject'}) > $maxsubjectlength ) { $message->{'subject'} = substr($message ->{'subject'},0,$maxsubjectlength) . '...'; }
2750 if ( length($message->{'sender'}) > $maxsenderlength ) { $message->{'sender'} = substr($message->{ 'sender'},0,$maxsenderlength); }
2751 if (( $message->{assignedto} ) and ($user{name} eq $message->{'assignedto'}) ) { $message->{mine} = 1; }
2752 push @messagelist, $message;
2753 }
2754
2755
2756 my $time_list = time() - $start_time;
2757
2758 my %queue;
2759 $queue{name} = $queuename;
2760 $queue{id} = $user{qid};
2761
2762 my $ptime = time() - $start_time;
2763 #my @chatter = getchat($user{qid},20);
2764 my $vars = {
2765 nav => \%nav,
2766 queue => \%queue,
2767 messagelist => \@messagelist,
2768 chatter => \@chatter,
2769 page => \%page_links,
2770 time_enter => $time_enter,
2771 time_check => $time_check,
2772 time_cleanlocks => $time_cleanlocks,
2773 time_killmylocks => $time_killmylocks,
2774 time_getuser => $time_getuser,
2775 time_before => $time_before,
2776 time_after => $time_after,
2777 time_list => $time_list,
2778 ptime => $ptime
2779
2780 };
2781 my $input = 'header.tmpl';
2782 $template->process($input, $vars) || return fail ($r, SERVER_ERROR, $template->error());
2783 $input = 'nav.tmpl';
2784 $template->process($input, $vars) || return fail ($r, SERVER_ERROR, $template->error());
2785 $input = 'messages.tmpl';
2786 $template->process($input, $vars) || return fail ($r, SERVER_ERROR, $template->error());
2787 $input = 'footer.tmpl';
2788 $template->process($input, $vars) || return fail ($r, SERVER_ERROR, $template->error());
2789 return OK;
2790 }
==> apache/logs/error_log <==
[Fri Nov 21 13:24:08 2003] [warn] [message] (123.123.123.123) Running query SELECT count(eid) from queue_foo_email
[Fri Nov 21 13:24:08 2003] [warn] [message] (123.123.123.123) Running query SELECT count(eid) from queue_foo_email WHERE date_read IS NULL
[Fri Nov 21 13:24:08 2003] [warn] (123.123.123.123) Running query SELECT e.eid, e.sender, e.subject, e.level, e.date_read, e.locked, e.hasattach, e.hasnote, e.assigned_to, to_char(t.stamp,'FMMM/FMDD/FMYY HH24:MI'), u.name FROM queue_foo_timestamp t, queue_foo_email e LEFT JOIN users u ON e.assigned_to = u.uid WHERE e.eid = t.eid ORDER BY e.
level DESC, t.stamp DESC LIMIT 20
Argument "someguy" isn't numeric in numeric gt (>) at (eval 93) line 24 (#2)
(W numeric) The indicated string was fed as an argument to an operator
that expected a numeric value instead. If you're fortunate the message
will identify which operator was so unfortunate.
Argument "someguy" isn't numeric in numeric gt (>) at (eval 93) line 24.
diagnostics::warn_trap('Argument "someguy" isn\'t numeric in numeric gt (>) at (eval ...') called at (eval 93) line 24
eval {...} called at (eval 93) line 7
Template::Document::__ANON__('Template::Context=HASH(0x8b92cec)') called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Document.pm line 141
eval {...} called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Document.pm line 139
Template::Document::process('Template::Document=HASH(0x85ec3bc)','Template::Context=HASH(0x8b92cec)') called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Context.pm line 336
eval {...} called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Context.pm line 320
Template::Context::process('Template::Context=HASH(0x8b92cec)','Template::Document=HASH(0x85ec3bc)') called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Service.pm line 97
eval {...} called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template/Service.pm line 94
Template::Service::process('Template::Service=HASH(0x85ef2cc)','messages.tmpl','HASH(0x85ed4cc)') called at /usr/local/lib/perl5/site_perl/5.8.1/i686-linux/Template.pm line 76
Template::process('Template=HASH(0x85ee3f0)','messages.tmpl','HASH(0x85ed4cc)') called at /proj/q2/lib/Q2/Init.pm line 2783
Q2::Init::handler('Apache=SCALAR(0x8b26f64)') called at /dev/null line 0
eval {...} called at /dev/null line 0
[Fri Nov 21 12:24:45 2003] [info] [client 123.123.123.123 ] (32)Broken pipe: client stopped connection before rwrite completed
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2003-11-21 at 17:26, Jordan Lederman wrote:
> I'll try that shortly. Are there any details available on what the problem
> with postgres are/were?
http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=75733;search_string=0x49;
I gather it involves problems with leaking file descriptors.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
I'll try that shortly. Are there any details available on what the problem
with postgres are/were?
--jordan
On Friday 21 November 2003 02:06 pm, Perrin Harkins wrote:
> On Fri, 2003-11-21 at 13:26, Jordan Lederman wrote:
> > The project is an web-based groupware email system which runs as
> > a mod_perl module on apache 1.3.28.
>
> Please try upgrading to 1.3.29. There are known problems with Postgres
> and apache 1.3.28.
>
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2003-11-21 at 13:26, Jordan Lederman wrote:
> The project is an web-based groupware email system which runs as
> a mod_perl module on apache 1.3.28.
Please try upgrading to 1.3.29. There are known problems with Postgres
and apache 1.3.28.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-11-24 at 16:17, Jordan Lederman wrote:
> The only thing that sticks in my mind about this is
> that I'm never explicitly releasing the connections. Won't I run out or
> waste/leak memory over time?
If you always use the same connection info, you should have one
connection per process, that will close when the process exits.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Monday 24 November 2003 04:13 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:57, Jordan Lederman wrote:
> > The my $dbh line above is located at the beginning of the file. When I
> > copy it to the beginning of the sub all is fixed!
>
> Apache::DBI tries to help you by not keeping persistent copies of
> database handles that you open during startup. In this case, the
> persistence was caused by you: you were creating a closure variable by
> declaring $dbh as a lexical outside of your subs and then using it
> within them. That made the database connection stay alive when apche
> forked, causing mayhem as multiple processes try to write to the same
> socket.
>
> > where is the proper place for this line?
>
> You should either call DBI->connect inside each sub, pass the database
> handle around to each sub that needs it, or create a singleton class
> that all subs call to get a database handle. The advantage of the
> singleton is just that you don't need to have you connection info all
> over the place. Here's an example:
>
> package Q2::DB;
>
> use strict;
> use warnings;
>
> use Carp qw(croak);
>
> sub get_dbh {
> my $dbh = DBI->connect(
> "dbi:Pg:dbname=queue",
> "queued",
> "",
> {
> AutoCommit => 1,
> RaiseError => 1,
> PrintError => 1,
> },
> )
> or croak "Cannot connect to db: $DBI::errstr";
> return $dbh;
> }
>
> Then just call my $dbh = Q2::DB::get_dbh() from your subs.
>
> - Perrin
Thanks so much for your help, and I like this idea (Q2::DB) very much as it's
clean and straightforward. It works great and i'm in the process of changing
my module over right now. The only thing that sticks in my mind about this is
that I'm never explicitly releasing the connections. Won't I run out or
waste/leak memory over time?
--jordan
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-11-24 at 15:57, Jordan Lederman wrote:
> The my $dbh line above is located at the beginning of the file. When I copy it
> to the beginning of the sub all is fixed!
Apache::DBI tries to help you by not keeping persistent copies of
database handles that you open during startup. In this case, the
persistence was caused by you: you were creating a closure variable by
declaring $dbh as a lexical outside of your subs and then using it
within them. That made the database connection stay alive when apche
forked, causing mayhem as multiple processes try to write to the same
socket.
> where is the proper place for this line?
You should either call DBI->connect inside each sub, pass the database
handle around to each sub that needs it, or create a singleton class
that all subs call to get a database handle. The advantage of the
singleton is just that you don't need to have you connection info all
over the place. Here's an example:
package Q2::DB;
use strict;
use warnings;
use Carp qw(croak);
sub get_dbh {
my $dbh = DBI->connect(
"dbi:Pg:dbname=queue",
"queued",
"",
{
AutoCommit => 1,
RaiseError => 1,
PrintError => 1,
},
)
or croak "Cannot connect to db: $DBI::errstr";
return $dbh;
}
Then just call my $dbh = Q2::DB::get_dbh() from your subs.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Monday 24 November 2003 03:49 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:35, Jordan Lederman wrote:
> > > You just have to look at the code you run from httpd.conf and
> > > startup.pl to see if it opens any connections. The code you posted
> > > looks fine, but what's in Q2::Init?
> >
> > 25 $Apache::DBI::DEBUG = 2;
> > 26
> > 27 my $dbh = DBI->connect("dbi:Pg:dbname=queue", "queued","",
> > { AutoCommit=> 1, RaiseError => 1, PrintError
> >
> > > 1 } ) or die "Cannot connect to db: $DBI::errstr \n";
>
> Is that inside a sub, or just in the main section of the module? If
> it's in the main part of the module, can you remove it and connect
> later?
>
The my $dbh line above is located at the beginning of the file. When I copy it
to the beginning of the sub all is fixed!. This leaves me a little puzzled.
Since I need to use the dbh at many different points in my module, I figured
declaring it at the top would be the way to go. Since I am obvoisly wrong,
where is the proper place for this line? Should it be decarled just inside of
the sub handler { ..} sub? Should I declare one for each sub that will
connect to the db (and if so, do I need to do any cleanup, ->finish,
->disconnect ...). What is the best/proper solution?
--jordan
> > I am a bit confused on why I need to connect to the db both in startup.pl
> > and in my module. Can you shed any light on this?
>
> Your connect_on_init() in startup.pl tells Apache::DBI you want it to
> create a connection when it spawns child processes. However, to access
> a cached connection in your module, you call DBI->connect and
> Apache::DBI intercepts that and hands you back a cached connection if
> there is one.
>
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-11-24 at 15:35, Jordan Lederman wrote:
> > You just have to look at the code you run from httpd.conf and startup.pl
> > to see if it opens any connections. The code you posted looks fine, but
> > what's in Q2::Init?
>
> 25 $Apache::DBI::DEBUG = 2;
> 26
> 27 my $dbh = DBI->connect("dbi:Pg:dbname=queue", "queued","",
> { AutoCommit=> 1, RaiseError => 1, PrintError
> > 1 } ) or die "Cannot connect to db: $DBI::errstr \n";
Is that inside a sub, or just in the main section of the module? If
it's in the main part of the module, can you remove it and connect
later?
> I am a bit confused on why I need to connect to the db both in startup.pl and
> in my module. Can you shed any light on this?
Your connect_on_init() in startup.pl tells Apache::DBI you want it to
create a connection when it spawns child processes. However, to access
a cached connection in your module, you call DBI->connect and
Apache::DBI intercepts that and hands you back a cached connection if
there is one.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Monday 24 November 2003 03:35 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:11, Jordan Lederman wrote:
> > Honestly I don't yet know enough to tell you.
>
> You just have to look at the code you run from httpd.conf and startup.pl
> to see if it opens any connections. The code you posted looks fine, but
> what's in Q2::Init?
25 $Apache::DBI::DEBUG = 2;
26
27 my $dbh = DBI->connect("dbi:Pg:dbname=queue", "queued","",
{ AutoCommit=> 1, RaiseError => 1, PrintError
> 1 } ) or die "Cannot connect to db: $DBI::errstr \n";
I am a bit confused on why I need to connect to the db both in startup.pl and
in my module. Can you shed any light on this?
--jordan
>
> > If nothing useful is found here, i'll begin working on makeing the
> > problem happen in a smaller context.
>
> Yes, I'm afraid you do need to do that. You may find the problem by
> doing it.
>
> > > The restart command just sends a SIGHUP. That doesn't usually work
> > > perfectly with mod_perl. I always do a stop and start.
> >
> > I had thought that it was my fault. :)
>
> There's lots of discussion about this in the mail archives, if you
> search for SIGHUP or HUP. The gist of it is that you may leak memory
> this way, and the behavior with regard to what happens in the Perl
> interpreter is different in a DSO build and a static build. I always
> use static builds, no PerlFreshRestart, and cold stop/start, because it
> reduces the number of things that can go wrong.
>
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-11-24 at 15:11, Jordan Lederman wrote:
> Honestly I don't yet know enough to tell you.
You just have to look at the code you run from httpd.conf and startup.pl
to see if it opens any connections. The code you posted looks fine, but
what's in Q2::Init?
> If nothing useful is found here, i'll begin working on makeing the problem
> happen in a smaller context.
Yes, I'm afraid you do need to do that. You may find the problem by
doing it.
> > The restart command just sends a SIGHUP. That doesn't usually work
> > perfectly with mod_perl. I always do a stop and start.
> >
>
> I had thought that it was my fault. :)
There's lots of discussion about this in the mail archives, if you
search for SIGHUP or HUP. The gist of it is that you may leak memory
this way, and the behavior with regard to what happens in the Perl
interpreter is different in a DSO build and a static build. I always
use static builds, no PerlFreshRestart, and cold stop/start, because it
reduces the number of things that can go wrong.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Monday 24 November 2003 03:05 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 14:54, Jordan Lederman wrote:
> > Well I've upgraded apache and mod_perl to 1.29 and I'm still having the
> > same issue.
>
> Are you opening database connections during server startup? That could
> cause this, if you have a connection open when the server forks. If
> that's not it, you need to reduce the problem to a short chunk of code
> that you can post.
>
Honestly I don't yet know enough to tell you. Here are the relevant sections
from my 3 config files:
httpd.conf:
AddHandler cgi-script .cgi
AddType text/html .shtml
AddHandler server-parsed .shtml
PerlModule Apache::DBI
PerlModule Template
PerlWarn On
PerlRequire /proj/q2/lib/startup.pl
Include conf/mod_perl.conf
PerlSetVar q2_root /proj/q2/tmpl
PerlSetVar q2_baseurl /q2/
PerlSetVar q2_basedir /proj/q2/
PerlSetVar q2_dbname queue
PerlSetVar q2_dbuser queued
startup.pl
use LWP::UserAgent ();
use Apache::DBI ();# use DBI ();
use DBD::Pg ();
use Apache::Cookie ();
use Apache::Constants (); #qw(:common);
use Storable;
use diagnostics;
use Apache::Request;
use Apache::File ();
use IPC::Shareable ();
use Data::Dumper;
Apache::DBI->connect_on_init
("DBI:Pg:dbname=queue",
"queued",
"",
{
PrintError => 1, # warn() on errors
RaiseError => 0, # don't die on error
AutoCommit => 1, # commit executes immediately
}
);
use Apache::Constants qw(M_GET);
# Tell me more about warnings
use Carp ();
$SIG{__WARN__} = \&Carp::cluck;
warn "Running $0 \n";
1;
mod_perl.conf:
PerlModule Q2::Init
<Location /q2>
SetHandler perl-script
perlHandler Q2::Init
PerlSendHeader Off
</Location>
If nothing useful is found here, i'll begin working on makeing the problem
happen in a smaller context.
> > 2) At some point during my development, apachectl reload stopped working
> > for me.
>
> The restart command just sends a SIGHUP. That doesn't usually work
> perfectly with mod_perl. I always do a stop and start.
>
I had thought that it was my fault. :)
--jordan
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Mon, 2003-11-24 at 14:54, Jordan Lederman wrote:
> Well I've upgraded apache and mod_perl to 1.29 and I'm still having the same
> issue.
Are you opening database connections during server startup? That could
cause this, if you have a connection open when the server forks. If
that's not it, you need to reduce the problem to a short chunk of code
that you can post.
> 2) At some point during my development, apachectl reload stopped working for
> me.
The restart command just sends a SIGHUP. That doesn't usually work
perfectly with mod_perl. I always do a stop and start.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Friday 21 November 2003 08:15 pm, Perrin Harkins wrote:
> On Fri, 2003-11-21 at 19:13, Jordan Lederman wrote:
> > The page located at http://perl.apache.org/docs/1.0/guide/
> > debug.html#Handling_the__User_pressed_Stop_button__case
> > says that things can be more complex with mod_perl.... can you shed any
> > light on that for me?
>
> It simply means that filehandles and other global resources are not
> automatically cleared for you at the end of a request, since the Perl
> interpreter is not exiting. Again, I don't think this is the cause of
> your problems, since apache no longer kills your script when the client
> breaks the connection. What is LogLevel set to in your httpd.conf? If
> it's info or debug, you get these warnings even though they are
> harmless.
>
The loglevel is set to info.
> I expect that either your problem will go away when you upgrade apache
> or it is a bug in your DBI code somewhere. If upgrading doesn't help,
> try to trim down your code to a simple example that demonstrates the
> issue.
Well I've upgraded apache and mod_perl to 1.29 and I'm still having the same
issue. It basically just feels like I'm running a long (takes ~ .5 seconds)
query when I hit stop and reload. When the next query is run, it receives a
piece of data from the query that was left running.
Some things that are/I've noticed:
1) The page I'm loading runs three individual queries - 2 select count(*),
and one larger data query. The first count query often receives results of
the 3rd (data) query.
2) At some point during my development, apachectl reload stopped working for
me. The command itself works, but my module cannot find a db connection after
this is run. The error I get is:
DBD::Pg::st execute failed: server closed the connection unexpectedly at /
proj/q2/lib/Q2/Init.pm line 2711.
DBD::Pg::st execute failed: server closed the connection unexpectedly at /
proj/q2/lib/Q2/Init.pm line 2711.
diagnostics::warn_trap('DBD::Pg::st execute failed: server closed the
connection unex...') called at /proj/q2/lib/Q2/Init.pm line 2711
To get around this, I have to do an apachectl stop; apachectl startssl.
3) The error is triggered more often when using mozilla firebird as opposed
to konqueror and IE.
I'm still waiting for the cookbook, but I think #2 above may have something to
do with the problem. Any ideas, tips, etc?
>
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2003-11-21 at 19:13, Jordan Lederman wrote:
> The page located at http://perl.apache.org/docs/1.0/guide/
> debug.html#Handling_the__User_pressed_Stop_button__case
> says that things can be more complex with mod_perl.... can you shed any light
> on that for me?
It simply means that filehandles and other global resources are not
automatically cleared for you at the end of a request, since the Perl
interpreter is not exiting. Again, I don't think this is the cause of
your problems, since apache no longer kills your script when the client
breaks the connection. What is LogLevel set to in your httpd.conf? If
it's info or debug, you get these warnings even though they are
harmless.
I expect that either your problem will go away when you upgrade apache
or it is a bug in your DBI code somewhere. If upgrading doesn't help,
try to trim down your code to a simple example that demonstrates the
issue.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Friday 21 November 2003 06:58 pm, Perrin Harkins wrote:
> On Fri, 2003-11-21 at 18:25, Jordan Lederman wrote:
> > Just read it -- and I'm trying to digest it all.
>
> I actually don't think it applies to your problem. You're not supposed
> to get that error anymore from users pressing stop, as I understand it.
> Are you using the latest mod_perl?
>
I'm using 1.28 with apache 1.3.28. I'll be upgrading to the latest (1.3.x)
version as soon as I can fix a small bug in apachetoolbox (it wants to use
mod_perl 1.99 for apache 1.3 for some odd reason).
The page located at http://perl.apache.org/docs/1.0/guide/
debug.html#Handling_the__User_pressed_Stop_button__case
says that things can be more complex with mod_perl.... can you shed any light
on that for me?
--jordan
> > Also, do I need to do a $dbh->sync ever, or is that just when working
> > with dbm files?
>
> No, that's just for dbm files, and I would advise people to use
> MLDBM::Sync and not worry about it.
>
> > Looks like I'll be stopping by the book store on my way home from work
> > tonight... :)
>
> A good idea, regardless.
>
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2003-11-21 at 18:25, Jordan Lederman wrote:
> Just read it -- and I'm trying to digest it all.
I actually don't think it applies to your problem. You're not supposed
to get that error anymore from users pressing stop, as I understand it.
Are you using the latest mod_perl?
> Also, do I need to do a $dbh->sync ever, or is that just when working with dbm
> files?
No, that's just for dbm files, and I would advise people to use
MLDBM::Sync and not worry about it.
> Looks like I'll be stopping by the book store on my way home from work
> tonight... :)
A good idea, regardless.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Jordan Lederman <jl...@advance.net>.
On Friday 21 November 2003 02:28 pm, Ged Haywood wrote:
> Hi there,
>
> On Fri, 21 Nov 2003, Jordan Lederman wrote:
> > if I hit reload quickly ...
> > (32)Broken pipe: client stopped connection...
> > what 'feels' like is happening is that...
> > When i hit reload before the queries are done...
> > often the value of $page_links{numtotal} is 'someguy'
> > which is a value found in the u.name field of the other query below.
>
> Have you seen
>
> http://perl.apache.org/docs/1.0/guide/debug.html#Handling_the__User_pressed
>_Stop_button__case
>
Just read it -- and I'm trying to digest it all. Most of the examples seem to
pertain more to scripts running under Apache::Registry then as a module but
it makes sense either way. However, I'm still not sure how to do this. Where
would I put such a test to see if the user has disconnected? Do I need an END
{ ... } block, and if so what would I put inside?
Also, do I need to do a $dbh->sync ever, or is that just when working with dbm
files?
> and also section 4.9 in the "mod_perl Developer's Cookbook"?
>
Looks like I'll be stopping by the book store on my way home from work
tonight... :)
--jordan
> 73,
> Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl + DBI + TT2 giving odd results
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Fri, 21 Nov 2003, Jordan Lederman wrote:
> if I hit reload quickly ...
> (32)Broken pipe: client stopped connection...
> what 'feels' like is happening is that...
> When i hit reload before the queries are done...
> often the value of $page_links{numtotal} is 'someguy'
> which is a value found in the u.name field of the other query below.
Have you seen
http://perl.apache.org/docs/1.0/guide/debug.html#Handling_the__User_pressed_Stop_button__case
and also section 4.9 in the "mod_perl Developer's Cookbook"?
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html