You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by David Wheeler <da...@kineticode.com> on 2003/08/13 21:04:34 UTC
Re: mod_perl + Apache 1.3.28
On Monday, July 28, 2003, at 03:44 AM, Stas Bekman wrote:
> David Wheeler wrote:
>> Hi All,
>> I just ran into some very strange issues with connections to a
>> PostgreSQL database (using DBD::Pg) getting unceremoniously dropped
>> by my mod_perl application. I was getting error messages such as
>> these:
>> [Tue Jul 22 13:21:44 2003] [error] [client 207.172.11.148] Unable to
>> turn AutoCommit off: DBD driver has not implemented the AutoCommit
>> attribute at /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm
>> line 528, <GEN71> line 57.
>> Database handle destroyed without explicit disconnect at
>> /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
>> Database handle destroyed without explicit disconnect at
>> /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
>> commit ineffective with AutoCommit enabled at
>> /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 571.
>> Database handle destroyed without explicit disconnect at
>> /usr/local/lib/perl5/site_perl/5.8.0/Bric/Util/DBI.pm line 1661.
>> The PostgreSQL log had these errors:
>> FATAL: Socket command type H unknown
>> FATAL: Socket command type 0 unknown
>> LOG: pq_flush: send() failed: Broken pipe
>> After a great deal of experimentation and recompilation, I finally
>> identified Apache 1.3.28 as the culprit. When I reverted to 1.3.27,
>> the problem went away.
>> I had a look at the Apache changelog to see what might have caused
>> this issue in Apache 1.3.28, and the most relevant item I found was
>> this:
>> *) Certain 3rd party modules would bypass the Apache API and not
>> invoke ap_cleanup_for_exec() before creating sub-processes.
>> To such a child process, Apache's file descriptors (lock
>> fd's, log files, sockets) were accessible, allowing them
>> direct access to Apache log file etc. Where the OS allows,
>> we now add proactive close functions to prevent these file
>> descriptors from leaking to the child processes.
>> [Jim Jagielski, Martin Kraemer]
>> Now it's possible that this affects mod_perl and its connections to
>> PostgreSQL, though I have no idea how. Could it be that mod_perl is
>> one of the 3rd party modules that's breaking this rule? Or could it
>> be some other change that led to this problem?
>> Note that although I replicated this problem on FreeBSD and on Mac OS
>> X (and had a report of the same issue from a Solaris user) with
>> mod_perl 1.28 and 1.27, it disappeared when I ran Apache in
>> single-process mode. I'm guessing that the problem is with either a)
>> Apache (ack!); b) The way Apache binds mod_perl (I've got mod_perl
>> 1.x statically compiled against Apache 1.3.x, of course); or c)
>> Something to do with the way DBI or DBD::Pg does something. My guess
>> is b, but wouldn't rule out a; c would be pretty strange.
>> At any rate, does anyone have any idea what could be causing problems
>> such as these?
>
> How does it behave under mod_cgi? if it's possible to write a test
> case to be run-able under mod_cgi.
I don't know. Bricolage is a massive application, and I'd have to do a
lot of work, I think, to isolate a test case.
> How mod_perl is related to running subprocesses?
I don't understand the question. AFAIK, there are no subprocesses other
than the Apache children (mod_perl1 is statically compiled into
Apache). I don't know how DBI establishes its connections to the
database server, but I can tell you that PostgreSQL runs a fork and
exec model similar to Apache 1's.
> Does your app spawn a subprocess? Apache::SubProcess provides the
> cleanup_for_exec() perl API if you do. It's also documented in the mp1
> guide.
No, no subprocesses as far as I know.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-08-13 at 16:56, Vivek Khera wrote:
> Actually, there is a good reason not to use Apache::DBI sometimes.
> For me, I have common modules for my command line apps and the web app
> to manipulate my overall system. I had to roll my own cached file
> handle because Apache::DBI won't even load outside of mod_perl.
Command-line apps typically don't need persistent connections. If they
do, I would make them call connect_cached when $ENV{'MOD_PERL'} is
undefined.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "PH" == Perrin Harkins <pe...@elem.com> writes:
PH> On Wed, 2003-08-13 at 16:07, David Wheeler wrote:
>> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
>> The code that's causing the hangup looks like this:
PH> First, we all need to yell at you for not using Apache::DBI. Your code
PH> is not doing anything that it doesn't do, and is actually doing less to
PH> ensure safety when something crashes. Apache::DBI would issue a
PH> rollback if some code crashed part-way through a request.
Actually, there is a good reason not to use Apache::DBI sometimes.
For me, I have common modules for my command line apps and the web app
to manipulate my overall system. I had to roll my own cached file
handle because Apache::DBI won't even load outside of mod_perl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 01:35 PM, Perrin Harkins wrote:
>> Not sure I want to go into hacking DBD::Pg's internals at this
>> point...
>
> Just remove the ping check from your _connect code and see what
> happens.
Interesting. Exactly the same result:
========================================================================
4404: Checking for DB handle.
4404: No handle, connecting.
4404: Checking for DB handle.
4405: Checking for DB handle.
4405: No handle, connecting.
4405: Checking for DB handle.
4405: Checking for DB handle.
4405: Checking for DB handle.
4405: Checking for DB handle.
4404: Checking for DB handle.
4404: Checking for DB handle.
[Wed Aug 13 22:26:32 2003] [error] [client 127.0.0.1] Unable to turn
AutoCommit off: DBD driver has not implemented the AutoCommit attribute
at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 528, <GEN5> line 8.
[/usr/local/bricolage/lib/Bric/Util/DBI.pm:529]
[/usr/local/bricolage/lib/Bric/App/Handler.pm:247]
In addition, the database rollback failed: Unable to rollback
transactions: DBD::Pg::db rollback failed: rollback failed at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 960, <GEN5> line 8.
[/usr/local/bricolage/lib/Bric/Util/DBI.pm:961]
[/usr/local/bricolage/lib/Bric/App/Handler.pm:284]
[/usr/local/bricolage/lib/Bric/App/Handler.pm:255]
[Wed Aug 13 22:26:32 2003] [error] Error during compilation of
/usr/local/bricolage/comp/errors/500.mc:
Global symbol "$r" requires explicit package name at
/usr/local/bricolage/comp/errors/500.mc line 118.
Global symbol "$r" requires explicit package name at
/usr/local/bricolage/comp/errors/500.mc line 2.
Stack:
[Wed Aug 13 22:26:32 2003] [info] [client 127.0.0.1] (9)Bad file
descriptor: client stopped connection before rflush completed
4404: Checking for DB handle.
4404: Checking for DB handle.
4404: Checking for DB handle.
[Wed Aug 13 22:26:32 2003] [error] Unable to rollback transactions:
DBD::Pg::db rollback failed: rollback failed at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 960.
[/usr/local/bricolage/lib/Bric/Util/DBI.pm:961]
[/usr/local/bricolage/lib/Bric/App/CleanupHandler.pm:131]
========================================================================
On the next restart, however, the first request succeeded, but then the
second did this:
4422: Checking for DB handle.
4422: No handle, connecting.
4422: Checking for DB handle.
4423: Checking for DB handle.
4423: No handle, connecting.
4423: Checking for DB handle.
4423: Checking for DB handle.
4423: Checking for DB handle.
4423: Checking for DB handle.
4425: Checking for DB handle.
4425: No handle, connecting.
4425: Checking for DB handle.
4425: Checking for DB handle.
4425: Checking for DB handle.
4422: Checking for DB handle.
4422: Checking for DB handle.
[Wed Aug 13 22:28:18 2003] [error] Unable to rollback transactions:
DBD::Pg::db rollback failed: rollback failed at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 960.
[/usr/local/bricolage/lib/Bric/Util/DBI.pm:961]
[/usr/local/bricolage/lib/Bric/App/CleanupHandler.pm:131]
========================================================================
I have no idea why it was trying to rollback there. It was hung there,
and when I cancelled the request from my browser, it didn't log
anything more.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-08-13 at 16:31, David Wheeler wrote:
> > Try changing your ping method or removing the ping and see if the
> > problem persists.
>
> Not sure I want to go into hacking DBD::Pg's internals at this point...
Just remove the ping check from your _connect code and see what happens.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Wed, 13 Aug 2003, David Wheeler wrote:
> >> You can see that this gets really ugly. Anyone seen anything like
> >> this,
> >> or have any idea what could be causing these problems?
> >
> > Try changing your ping method or removing the ping and see if the
> > problem persists.
>
> Not sure I want to go into hacking DBD::Pg's internals at this point...
>
here is a patch that gives some more info on what is going on in ping():
pandora:~/dbdpg/head/dbdpg:$ cvs diff -u dbdimp.c
Index: dbdimp.c
===================================================================
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/dbdimp.c,v
retrieving revision 1.28
diff -u -r1.28 dbdimp.c
--- dbdimp.c 23 Jul 2003 13:35:46 -0000 1.28
+++ dbdimp.c 13 Aug 2003 21:08:55 -0000
@@ -281,9 +281,13 @@
if (dbis->debug >= 1) { PerlIO_printf(DBILOGFP, "dbd_db_ping\n");
}
if (NULL != imp_dbh->conn) {
+ PerlIO_printf(DBILOGFP, "before PQexec\n");
result = PQexec(imp_dbh->conn, " ");
+ PerlIO_printf(DBILOGFP, "result: %i\n", result);
status = result ? PQresultStatus(result) : -1;
+ PerlIO_printf(DBILOGFP, "status: %i\n", status);
PQclear(result);
+ PerlIO_printf(DBILOGFP, "PQclear\n");
if (PGRES_EMPTY_QUERY != status) {
return 0;
Rudy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 01:24 PM, Perrin Harkins wrote:
>> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
>> The code that's causing the hangup looks like this:
>
> First, we all need to yell at you for not using Apache::DBI. Your code
> is not doing anything that it doesn't do, and is actually doing less to
> ensure safety when something crashes. Apache::DBI would issue a
> rollback if some code crashed part-way through a request.
Yeah, this is some old code. I've been thinking about just using
Apache::DBI. Maybe then the problem'll just go away.
>> At this point, everything hangs, stuck in $dbh->ping.
>
> Does that happen under 1.3.27 too? Is this a nested transaction
> problem
> stemming from the subrequests?
No, it works fine under 1.3.27. There are no subrequests, only
secondary requests from the browser (for layers and such).
>> 4166: No handle, connecting. # This shouldn't happen!
>
> That would happen if it failed the ping.
I know, that's why it's so weird!
>> You can see that this gets really ugly. Anyone seen anything like
>> this,
>> or have any idea what could be causing these problems?
>
> Try changing your ping method or removing the ping and see if the
> problem persists.
Not sure I want to go into hacking DBD::Pg's internals at this point...
Thanks for the feedback, Perrin!
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Wed, 2003-08-13 at 17:30, Matt Sergeant wrote:
>
>>Unfortunately Apache::DBI is an ugly "action at a distance" hack :-)
>
>
> I agree, but having everyone implement their own is worse. It leads to
> lots of repeated work on solved problems. What would you suggest to fix
> it?
>
> My idea would be to leave Apache::DBI as it is for use with legacy CGI
> code and then add a new module to the distribution that is called
> explicitly so it has no "distance" issues. Maybe call it
> Apache::DBI::Factory?
>
> There could also be an attempt to reconcile Apache::DBI with
> DBI->connect_cached. AFAIK, the only features Apache::DBI has over
> connect_cached are the rollback cleanup handler and the transparency
> part, which we don't like. Apache::DBI::Factory could just call
> connect_cached and add the cleanup part.
Don't forget that I've started working on DBI::Pool, which should work
transparently for threads and processes with and without mod_perl. So if you
want to spend any effort on a replacement for Apache::DBI, I'd suggest to join
the efforts. At the moment I'm too busy with mp2 issues, so if anybody wants
to pick the flag and get the module past the prototype phase, that would be great.
It has no external face yet, so you can do whatever you want. the hard part
was to provide an internal support from DBI, which is almost there.
Check this thread:
http://archive.develooper.com/dbi-dev@perl.org/msg02134.html
There was a lot of discussion happening around this item:
http://www.geocrawler.com/mail/thread.php3?subject=rfc%3A+DBI%3A%3APool+prototype+%28i.e.+hack%29&list=184
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Friday, August 15, 2003, at 07:41 AM, Tim Bunce wrote:
>> So, do I need to ask anyone other than you, Perrin? Tim, are you
>> listening? Is this still somewhat experimental?
>
> It's not changed in a long time so I guess not :)
> I'll remove that note.
S'what I thought. And since it solved my problem I'm doubly thankful!
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Tim Bunce <Ti...@pobox.com>.
On Thu, Aug 14, 2003 at 11:39:12AM -0700, David Wheeler wrote:
> On Thursday, August 14, 2003, at 07:58 AM, Perrin Harkins wrote:
>
> >You guys should just be using DBI->connect_cached then. It does
> >everything except the mod_perl cleanup handler.
> >
> >Note that I still write a utility class that knows where to get the
> >database config and returns a connection, but I don't worry about doing
> >anything to keep the connection persistent or ping it, and that's what
> >Apache::DBI or DBI->connect_cached will take care of for you.
>
> Checking it out, I see that the DBI docs say:
>
> >Caching can be useful in some applications, but it can also cause
> >problems and should be used with care. The exact behaviour of this
> >method is liable to change, so if you intend to use it in any
> >production applications you should discuss your needs on the dbi-users
> >mailing list.
>
> So, do I need to ask anyone other than you, Perrin? Tim, are you
> listening? Is this still somewhat experimental?
It's not changed in a long time so I guess not :)
I'll remove that note.
Tim.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Friday, August 15, 2003, at 07:02 PM, Rudy Lippan wrote:
>> Inside the eval? What difference does it make? There are only a couple
>> of (controlled) commits and begins inside that eval, and any
>> exceptions
>> cause the whole thing to be rolled back.
>>
> No. The question is, 'What was happening inside of DBD::Pg that was
> causing the db handle to get corrupted?'
And is there some way to clean up after that?
> That would be great ;) -- All I meant was that I had not added that
> item
> to the TODO file :)
begin_work() is in there.
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Thu, 14 Aug 2003, David Wheeler wrote:
> On Thursday, August 14, 2003, at 01:15 PM, Rudy Lippan wrote:
>
> >> Switching to connect_cached() seems to have made my problem with
> >> Apache
> >> 1.3.28 go away Yay! Oh, and BTW, I am doing cleanup by running my
> >> entire request in an eval:
> >
> > Yes, but there still is the open question of what is happening in
> > there.
>
> Inside the eval? What difference does it make? There are only a couple
> of (controlled) commits and begins inside that eval, and any exceptions
> cause the whole thing to be rolled back.
>
No. The question is, 'What was happening inside of DBD::Pg that was
causing the db handle to get corrupted?'
> >> Now, one more question: when are we going to see support for
> >> begin_work() in DBD::Pg?
> >
> > After 1.31 goes out :) Start working on a 1.(4|5) which would include
> > begin_work() -- Take a look at the TODO in cvs (and you can add
> > supprort
> > for the new command execution funtions to that).
>
> Yeah, yeah, patches welcome and all that. I'll add it to my own
> personal todo list! ;-)
That would be great ;) -- All I meant was that I had not added that item
to the TODO file :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Thursday, August 14, 2003, at 01:15 PM, Rudy Lippan wrote:
>> Switching to connect_cached() seems to have made my problem with
>> Apache
>> 1.3.28 go away Yay! Oh, and BTW, I am doing cleanup by running my
>> entire request in an eval:
>
> Yes, but there still is the open question of what is happening in
> there.
Inside the eval? What difference does it make? There are only a couple
of (controlled) commits and begins inside that eval, and any exceptions
cause the whole thing to be rolled back.
>> Rudy, I also find that the latest DBD::Pg in CVS compiles and tests
>> great on Mac OS X. We ready to package up 1.31_3 for general release
>> on
>> CPAN?
>
> Sweet! Someone reported a minor bug today on dbi-users that I think we
> can
> pull in to 1.31_3. So that will leave just the random segfault in
> the bind_param() tests.
Cool. I'm not familiar with that issue, and have never seen it.
>> Now, one more question: when are we going to see support for
>> begin_work() in DBD::Pg?
>
> After 1.31 goes out :) Start working on a 1.(4|5) which would include
> begin_work() -- Take a look at the TODO in cvs (and you can add
> supprort
> for the new command execution funtions to that).
Yeah, yeah, patches welcome and all that. I'll add it to my own
personal todo list! ;-)
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Thu, 14 Aug 2003, David Wheeler wrote:
>
> On Thursday, August 14, 2003, at 11:39 AM, David Wheeler wrote:
>
> >> Caching can be useful in some applications, but it can also cause
> >> problems and should be used with care. The exact behaviour of this
> >> method is liable to change, so if you intend to use it in any
> >> production applications you should discuss your needs on the
> >> dbi-users mailing list.
> >
> > So, do I need to ask anyone other than you, Perrin? Tim, are you
> > listening? Is this still somewhat experimental?
>
> Switching to connect_cached() seems to have made my problem with Apache
> 1.3.28 go away Yay! Oh, and BTW, I am doing cleanup by running my
> entire request in an eval:
>
Yes, but there still is the open question of what is happening in there.
> Rudy, I also find that the latest DBD::Pg in CVS compiles and tests
> great on Mac OS X. We ready to package up 1.31_3 for general release on
> CPAN?
Sweet! Someone reported a minor bug today on dbi-users that I think we can
pull in to 1.31_3. So that will leave just the random segfault in
the bind_param() tests.
> Now, one more question: when are we going to see support for
> begin_work() in DBD::Pg?
>
After 1.31 goes out :) Start working on a 1.(4|5) which would include
begin_work() -- Take a look at the TODO in cvs (and you can add supprort
for the new command execution funtions to that).
Rudy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Thursday, August 14, 2003, at 12:53 PM, David Wheeler wrote:
> Switching to connect_cached() seems to have made my problem with
> Apache 1.3.28 go away Yay!
Did I say this? It's back today! :-(
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /usr/local/lib/perl5/site_perl/5.8.0/darwin/DBI.pm line
1241, <GEN5> line 8.
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /usr/local/lib/perl5/site_perl/5.8.0/darwin/DBI.pm line
1241.
WARNING: ROLLBACK: no transaction in progress
message type 0x43 arrived from server while idle
WARNING: ROLLBACK: no transaction in progress
Attempt to free unreferenced scalar at
/usr/local/lib/perl5/site_perl/5.8.0/darwin/DBI.pm line 1241.
*** malloc[5380]: Deallocation of a pointer not malloced: 0x1daf6b0;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug
[Fri Aug 15 15:38:03 2003] [notice] child pid 5380 exit signal
Segmentation fault (11)
This despite the fact that I fixed my begin, commit, and rollback code
to work like this:
begin: $dbh->{AutoCommit} = 0 if $dbh->{AutoCommit};
commit: $dbh->commit unless $dbh->{AutoCommit}
rollback: $dbh->rollback unless $dbh->{AutoCommit}
And that I am now using connect_cached() instead of my own connection
caching scheme.
So turning on DBI->trace(9) again, I get the attached log. There were
several successful requests before the problem showed up again, so
apologies for the size of the file.
Interesting notes:
Segfault at line 1297. See notes there. This is weird because the
request appeared to be successful, from the browser's point of view.
Line 4004: This is where it finally hung. There were a fair number of
successful requests before it got to this point. What follows below
this line is what happened after I canceled the request from my
browser. As you can see, it's not pretty.
Anybody have any clue about this? Again, it only happens with Apache
1.3.28.
Thanks, and sorry for the bad news!
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Thursday, August 14, 2003, at 11:39 AM, David Wheeler wrote:
>> Caching can be useful in some applications, but it can also cause
>> problems and should be used with care. The exact behaviour of this
>> method is liable to change, so if you intend to use it in any
>> production applications you should discuss your needs on the
>> dbi-users mailing list.
>
> So, do I need to ask anyone other than you, Perrin? Tim, are you
> listening? Is this still somewhat experimental?
Switching to connect_cached() seems to have made my problem with Apache
1.3.28 go away Yay! Oh, and BTW, I am doing cleanup by running my
entire request in an eval:
sub handler {
my ($r) = @_;
# Handle the request.
my $status;
eval {
# Start the database transactions.
begin(1);
# Handle the request.
$status = $ah->handle_request($r);
# Commit the database transactions.
commit(1);
};
# Do error processing, if necessary.
return $@ ? handle_err($r, $@) : $status;
}
handle_err() of course does a rollback.
Rudy, I also find that the latest DBD::Pg in CVS compiles and tests
great on Mac OS X. We ready to package up 1.31_3 for general release on
CPAN?
I've also fixed the way AutoCommit is set up in Bric::Util::DBI, thanks
to your notes, Rudy. Hopefully we'll have no more problems!
Now, one more question: when are we going to see support for
begin_work() in DBD::Pg?
Many TIA to all who gave me feedback with this issue, especially Rudy
and Perrin.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Thursday, August 14, 2003, at 07:58 AM, Perrin Harkins wrote:
> You guys should just be using DBI->connect_cached then. It does
> everything except the mod_perl cleanup handler.
>
> Note that I still write a utility class that knows where to get the
> database config and returns a connection, but I don't worry about doing
> anything to keep the connection persistent or ping it, and that's what
> Apache::DBI or DBI->connect_cached will take care of for you.
Checking it out, I see that the DBI docs say:
> Caching can be useful in some applications, but it can also cause
> problems and should be used with care. The exact behaviour of this
> method is liable to change, so if you intend to use it in any
> production applications you should discuss your needs on the dbi-users
> mailing list.
So, do I need to ask anyone other than you, Perrin? Tim, are you
listening? Is this still somewhat experimental?
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2003-08-14 at 03:33, Matt Sergeant wrote:
> Yeah basically that sort of thing, but also allow it to be used outside
> mod_perl by making sure you wrap all the cleanup stuff in if
> ($ENV{MOD_PERL}) {} and do the cleanup in END{} otherwise. That's the
> main reason I roll my own - because I use it extensively outside of
> mod_perl (though like David, I'm also not doing cleanup *blush*).
You guys should just be using DBI->connect_cached then. It does
everything except the mod_perl cleanup handler.
Note that I still write a utility class that knows where to get the
database config and returns a connection, but I don't worry about doing
anything to keep the connection persistent or ping it, and that's what
Apache::DBI or DBI->connect_cached will take care of for you.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Thu, 14 Aug 2003, Matt Sergeant wrote:
> On Wednesday, Aug 13, 2003, at 22:46 Europe/London, Perrin Harkins
> wrote:
>
> > My idea would be to leave Apache::DBI as it is for use with legacy CGI
> > code and then add a new module to the distribution that is called
> > explicitly so it has no "distance" issues. Maybe call it
> > Apache::DBI::Factory?
> >
> > There could also be an attempt to reconcile Apache::DBI with
> > DBI->connect_cached. AFAIK, the only features Apache::DBI has over
> > connect_cached are the rollback cleanup handler and the transparency
> > part, which we don't like. Apache::DBI::Factory could just call
> > connect_cached and add the cleanup part.
>
> Yeah basically that sort of thing, but also allow it to be used outside
> mod_perl by making sure you wrap all the cleanup stuff in if
> ($ENV{MOD_PERL}) {} and do the cleanup in END{} otherwise. That's the
> main reason I roll my own - because I use it extensively outside of
> mod_perl (though like David, I'm also not doing cleanup *blush*).
>
I'll vote for that. I use a custom rolled connexion caching thingey too
mostly because I use mod_fastcgi at times, and I like to have code
that can be run in either a mod_perl env. or a fast_cgi env.
Hum cleanup... I don't think I am doing much of that either :)
Rudy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wednesday, Aug 13, 2003, at 22:46 Europe/London, Perrin Harkins
wrote:
> My idea would be to leave Apache::DBI as it is for use with legacy CGI
> code and then add a new module to the distribution that is called
> explicitly so it has no "distance" issues. Maybe call it
> Apache::DBI::Factory?
>
> There could also be an attempt to reconcile Apache::DBI with
> DBI->connect_cached. AFAIK, the only features Apache::DBI has over
> connect_cached are the rollback cleanup handler and the transparency
> part, which we don't like. Apache::DBI::Factory could just call
> connect_cached and add the cleanup part.
Yeah basically that sort of thing, but also allow it to be used outside
mod_perl by making sure you wrap all the cleanup stuff in if
($ENV{MOD_PERL}) {} and do the cleanup in END{} otherwise. That's the
main reason I roll my own - because I use it extensively outside of
mod_perl (though like David, I'm also not doing cleanup *blush*).
Matt.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-08-13 at 17:30, Matt Sergeant wrote:
> Unfortunately Apache::DBI is an ugly "action at a distance" hack :-)
I agree, but having everyone implement their own is worse. It leads to
lots of repeated work on solved problems. What would you suggest to fix
it?
My idea would be to leave Apache::DBI as it is for use with legacy CGI
code and then add a new module to the distribution that is called
explicitly so it has no "distance" issues. Maybe call it
Apache::DBI::Factory?
There could also be an attempt to reconcile Apache::DBI with
DBI->connect_cached. AFAIK, the only features Apache::DBI has over
connect_cached are the rollback cleanup handler and the transparency
part, which we don't like. Apache::DBI::Factory could just call
connect_cached and add the cleanup part.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wednesday, Aug 13, 2003, at 21:24 Europe/London, Perrin Harkins
wrote:
> On Wed, 2003-08-13 at 16:07, David Wheeler wrote:
>> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
>> The code that's causing the hangup looks like this:
>
> First, we all need to yell at you for not using Apache::DBI. Your code
> is not doing anything that it doesn't do, and is actually doing less to
> ensure safety when something crashes. Apache::DBI would issue a
> rollback if some code crashed part-way through a request.
Unfortunately Apache::DBI is an ugly "action at a distance" hack :-)
(And I'm on David's side - I never use it)
Matt.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-08-13 at 16:07, David Wheeler wrote:
> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
> The code that's causing the hangup looks like this:
First, we all need to yell at you for not using Apache::DBI. Your code
is not doing anything that it doesn't do, and is actually doing less to
ensure safety when something crashes. Apache::DBI would issue a
rollback if some code crashed part-way through a request.
> At this point, everything hangs, stuck in $dbh->ping.
Does that happen under 1.3.27 too? Is this a nested transaction problem
stemming from the subrequests?
> 4166: No handle, connecting. # This shouldn't happen!
That would happen if it failed the ping.
> You can see that this gets really ugly. Anyone seen anything like this,
> or have any idea what could be causing these problems?
Try changing your ping method or removing the ping and see if the
problem persists.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 08:27 PM, Rudy Lippan wrote:
> So then it is nothing that I did ;)
No, probably something I did. :-)
>> Intermittent.
>
> But always on the second requst to the first process?
Nope.
> It looks like something is happening to the Postgresql connection,
> which
> is throwing off DBD::Pg and it gets into a weird state, so when it
> goes to
> excute "BEGIN" pg is throwing an error -- Does the BEGIN even make it
> to
> the databaes server? What do your pg server logs say?
On the hang, I get this:
LOG: pq_recvbuf: unexpected EOF on client connection
> I did not see any ping releated info in the log file. Did you re-enable
> the ping in _connect()?
Oops, I didn't. Re-enabling for the next try.
> What is the first process doing (Process #4627), Because I don't see it
> executing any SQL statements other than flipping the state of
> Autocommit?
It's just redirecting the browser, I believe.
> I tried pulling a copy of Bric/Util/DBI.pm off of CVS on sourceforge
> but
> the line numbers were not matching what was in the trace -- which
> version
> should I be looking at?
I'm using the rev_1_6 branch, Revision 1.21.2.14. You can easily grab
just that file here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bricolage/bricolage/lib/
Bric/Util/DBI.pm
> Do you think that you might be able to put together a script that does
> not
> require Bric -- it is a bit of a large hairy beast to install just to
> try
> and duplicate the problem.
I was trying, but couldn't. Which is leading me think that somehow the
problem _is_ with Bricolage. This is good. Or bad, depending on your
POV. I could perhaps give you access to one of my systems running it...
> Something I noticed while looking at Bric::Util::DBI:
>
> sub commit {
> return 1 unless TRANSACTIONAL;
> return 1 if $ENV{MOD_PERL} && !$_[0];
> _connect(); #rl: <--- Back to
> autocommit.
> my $ret;
> eval { $ret = $dbh->commit }; #rl: <---- Roll back what?
> if
> #rl: you needed to
> reconnect?
> throw_da(error => "Unable to commit transactions", payload => $@)
> if $@;
> eval { $ret = $dbh->{AutoCommit} = 1 };
> throw_da(error => "Unable to turn AutoCommit on", payload => $@)
> if $@;
> return $ret;
> }
>
> Another case is where the DB server is restarted after a begin():
>
> $bric_dbh->begin();
> ### Database server is restarted. ###
> $bric_dbh->prepare(); # You _connect() here and are back in autocommit
> mode
>
> DO_STUF: {
> # everthing is automatically commited.
> }
> $bric_dbh->rollback() # does not do jack because you are in autocommit.
D'oh! Three years using this code and I never noticed that! I've
commented out the calls to _connect() in commit() and rollback().
> The above could could be what casues the commit ineffective in
> autocommit
> mode error messages. My guess is that things were getting stuck in
> ping,
> when you hit stop you poped out of whatever was blocking (on a signal?)
> and then the next db call you made automatically reconnected to the db
> which caused some of the other error messages that you were seeing in
> the
> logs?
Maybe, but with the above change, I'm still getting failures. I attach
a new log. Look for my comments where the hang occurred, marked by
"#########################################"
Thanks for the help with this, Rudy!
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Wed, 13 Aug 2003, David Wheeler wrote:
> On Wednesday, August 13, 2003, at 02:03 PM, Rudy Lippan wrote:
>
> > What version of DBD::Pg are you using for this test? Version of
> > mod_perl?
>
> 1.30 from CVS a couple of weeks ago, but I've seen it with 1.22, too.
>
So then it is nothing that I did ;)
> > Does this happen on every second request to httpd, or is it more
> > intermittent?
>
> Intermittent.
But always on the second requst to the first process?
> > Have you tried DBI->trace()? I would like to see a trace(9) for the
> > hits
> > that cause the problem.
>
> Will try it with your patch. See below.
>
> On Wednesday, August 13, 2003, at 02:10 PM, Rudy Lippan wrote:
>
> > here is a patch that gives some more info on what is going on in
> > ping():
>
> Applied, compiled, and installed. Attached are the results (with
> DBI->trace(9), too). Note that it looks like begin is failing. What
> might cause that to happen?
>
It looks like something is happening to the Postgresql connection, which
is throwing off DBD::Pg and it gets into a weird state, so when it goes to
excute "BEGIN" pg is throwing an error -- Does the BEGIN even make it to
the databaes server? What do your pg server logs say?
I did not see any ping releated info in the log file. Did you re-enable
the ping in _connect()?
What is the first process doing (Process #4627), Because I don't see it
executing any SQL statements other than flipping the state of Autocommit?
I tried pulling a copy of Bric/Util/DBI.pm off of CVS on sourceforge but
the line numbers were not matching what was in the trace -- which version
should I be looking at?
Do you think that you might be able to put together a script that does not
require Bric -- it is a bit of a large hairy beast to install just to try
and duplicate the problem.
Something I noticed while looking at Bric::Util::DBI:
sub commit {
return 1 unless TRANSACTIONAL;
return 1 if $ENV{MOD_PERL} && !$_[0];
_connect(); #rl: <--- Back to autocommit.
my $ret;
eval { $ret = $dbh->commit }; #rl: <---- Roll back what? if
#rl: you needed to reconnect?
throw_da(error => "Unable to commit transactions", payload => $@)
if $@;
eval { $ret = $dbh->{AutoCommit} = 1 };
throw_da(error => "Unable to turn AutoCommit on", payload => $@)
if $@;
return $ret;
}
Another case is where the DB server is restarted after a begin():
$bric_dbh->begin();
### Database server is restarted. ###
$bric_dbh->prepare(); # You _connect() here and are back in autocommit mode
DO_STUF: {
# everthing is automatically commited.
}
$bric_dbh->rollback() # does not do jack because you are in autocommit.
The above could could be what casues the commit ineffective in autocommit
mode error messages. My guess is that things were getting stuck in ping,
when you hit stop you poped out of whatever was blocking (on a signal?)
and then the next db call you made automatically reconnected to the db
which caused some of the other error messages that you were seeing in the
logs?
Rudy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 02:03 PM, Rudy Lippan wrote:
> What version of DBD::Pg are you using for this test? Version of
> mod_perl?
1.30 from CVS a couple of weeks ago, but I've seen it with 1.22, too.
> Does this happen on every second request to httpd, or is it more
> intermittent?
Intermittent.
> Can you get it to happen on every second request when
> running httpd under -X?
No, it works fine under -X.
> Have you tried DBI->trace()? I would like to see a trace(9) for the
> hits
> that cause the problem.
Will try it with your patch. See below.
On Wednesday, August 13, 2003, at 02:10 PM, Rudy Lippan wrote:
> here is a patch that gives some more info on what is going on in
> ping():
Applied, compiled, and installed. Attached are the results (with
DBI->trace(9), too). Note that it looks like begin is failing. What
might cause that to happen?
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: mod_perl + Apache 1.3.28
Posted by Rudy Lippan <rl...@remotelinux.com>.
On Wed, 13 Aug 2003, David Wheeler wrote:
> On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
>
> > I'm attempting to isolate the problem now.
>
What version of DBD::Pg are you using for this test? Version of mod_perl?
> The code that's causing the hangup looks like this:
>
> our $dbh;
> sub _connect {
> eval {
> warn "$$: Checking for DB handle.\n";
> unless ($dbh && $dbh->ping) {
> warn "$$: No handle, connecting.\n";
> $dbh = DBI->connect(join(':', 'DBI', DBD_TYPE, DSN_STRING),
> DBI_USER, DBI_PASS, $ATTR);
> }
> };
> die Bric::Util::Fault::Exception::DA->new(
> { msg => "Unable to connect to database", payload => $@ }) if
> $@;
> print STDERR "\n";
> }
>
Does this happen on every second request to httpd, or is it more
intermittent? Can you get it to happen on every second request when
running httpd under -X?
Have you tried DBI->trace()? I would like to see a trace(9) for the hits
that cause the problem.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 12:32 PM, David Wheeler wrote:
> I'm attempting to isolate the problem now.
The code that's causing the hangup looks like this:
our $dbh;
sub _connect {
eval {
warn "$$: Checking for DB handle.\n";
unless ($dbh && $dbh->ping) {
warn "$$: No handle, connecting.\n";
$dbh = DBI->connect(join(':', 'DBI', DBD_TYPE, DSN_STRING),
DBI_USER, DBI_PASS, $ATTR);
}
};
die Bric::Util::Fault::Exception::DA->new(
{ msg => "Unable to connect to database", payload => $@ }) if
$@;
print STDERR "\n";
}
END { _disconnect(); }
The _connect() function is called before every database action (query,
begin, commit, rollback, etc.).
I make a request to the server, and here's what appears in the log.
There are a couple of secondar requests in there, which is why there
are so many requests when I try to view one Bricolage page in the
browser. There are also two phases for each request, each using a
transaction, PerlHandler and PerlCleanupHandler (which handles
logging). This is what appears in the log (along with my comments on
what's going on).
========================================================================
4166: Checking for DB handle. # Initial request query
4166: No handle, connecting.
4166: Checking for DB handle. # PerlCleanupHandler
4167: Checking for DB handle. # Secondary request query
4167: No handle, connecting.
4167: Checking for DB handle. # Query
4167: Checking for DB handle. # Query
4167: Checking for DB handle. # Query
4167: Checking for DB handle. # PerlCleanupHandler
4166: Checking for DB handle. # Secondary request query
========================================================================
At this point, everything hangs, stuck in $dbh->ping. You can see that
this
child has been used before, so the database handle is of course
initialized,
but it uses $dbh->ping to make sure it's still connected to the server.
After a couple of minutes of waiting, I hit the cancel button on my
browser.
The log then gets the following (plus my comments):
========================================================================
4166: No handle, connecting. # This shouldn't happen!
4166: Checking for DB handle.
4166: No handle, connecting. # PerlCleanupHandler -- Handle corrupted?
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 1663.
commit ineffective with AutoCommit enabled at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 571.
4166: Checking for DB handle.
4166: No handle, connecting.
4166: Checking for DB handle.
4166: No handle, connecting.
Issuing rollback() for database handle being DESTROY'd without explicit
disconnect() at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 1663.
message type 0x49 arrived from server while idle # Now it gets ugly!
Attempt to free unreferenced scalar at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 1663.
*** malloc[4166]: Deallocation of a pointer not malloced: 0x1d60af0;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug
rollback ineffective with AutoCommit enabled at
/usr/local/bricolage/lib/Bric/Util/DBI.pm line 960.
[Wed Aug 13 19:51:11 2003] [error] [client 127.0.0.1] Unable to turn
AutoCommit off: DBD driver has not implemented the AutoCommit attribute
at /usr/local/bricolage/lib/Bric/Util/DBI.pm line 528.
[/usr/local/bricolage/lib/Bric/Util/DBI.pm:529]
[/usr/local/bricolage/lib/Bric/App/CleanupHandler.pm:125]
========================================================================
You can see that this gets really ugly. Anyone seen anything like this,
or have any idea what could be causing these problems? Again, this
happens only on Apache 1.3.28.
Many TIA,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by David Wheeler <da...@kineticode.com>.
On Wednesday, August 13, 2003, at 12:25 PM, Vivek Khera wrote:
> FWIW, my development box I updated to Apache 1.3.28, and my app
> doesn't seem to have the unceremonious disconnects to postgres that
> you observed. I haven't updated our production web server to apache
> 1.3.28 yet, though, so I don't know if it will fail under heavier
> load. I'm still running mod_perl 1.27_01-dev on both.
Okay. I found that I got the problem with mp1.27 and mp1.28, but only
with Apache 1.3.28, not with 1.3.27.
> I was very concerned when you posted the original note, and have been
> attempting to pound on it a bit to make it fail without success (or
> with success, depending on how you look at it :-)
I'm attempting to isolate the problem now.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: mod_perl + Apache 1.3.28
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "DW" == David Wheeler <da...@kineticode.com> writes:
DW> On Monday, July 28, 2003, at 03:44 AM, Stas Bekman wrote:
>> David Wheeler wrote:
>>> Hi All,
>>> I just ran into some very strange issues with connections to a
>>> PostgreSQL database (using DBD::Pg) getting unceremoniously dropped
>>> by my mod_perl application. I was getting error messages such as
>>> these:
[[ ... ]]
>>> After a great deal of experimentation and recompilation, I finally
>>> identified Apache 1.3.28 as the culprit. When I reverted to 1.3.27,
>>> the problem went away.
FWIW, my development box I updated to Apache 1.3.28, and my app
doesn't seem to have the unceremonious disconnects to postgres that
you observed. I haven't updated our production web server to apache
1.3.28 yet, though, so I don't know if it will fail under heavier
load. I'm still running mod_perl 1.27_01-dev on both.
I was very concerned when you posted the original note, and have been
attempting to pound on it a bit to make it fail without success (or
with success, depending on how you look at it :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org