Skip Menu |
 

This queue is for tickets about the Apache-DBI CPAN distribution.

Report information
The Basics
Id: 37272
Status: open
Priority: 0/
Queue: Apache-DBI

People
Owner: Nobody in particular
Requestors: cpan [...] funkreich.de
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.07
Fixed in: (no value)



Subject: Connecting during startup causes random "Out of Sync"/"Lost connection" MySQL errors for subsequent per-process connections
MIME-Version: 1.0
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Type: text/plain
Charset: utf8
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1255
Download (untitled) / with headers
text/plain 1.2k
I've already discussed this on the mod_perl mailing list. The following minimal mod_perl application works perfectly without Apache::DBI. As soon as I add it to the mix and hammer the application with "ab -n 1000 -c 15" I'm getting a couple of "Lost connection to MySQL server" and "Commands out of sync" errors from MySQL shortly after starting the benchmark. http://www.gossamer-threads.com/lists/modperl/modperl/97620#97620 If I use two different connection strings (e.g. with different attributes) everything works with Apache::DBI. If I remove the connect during startup, it works, too. In any case, the expected "skipping connection during server startup" warning shows up but it seems that when both connections (the one made during startup and the subsequent connections during handler()) have identical DSNs and attributes Apache::DBI re-uses the connection made during startup. Due to the fact that nobody on the mod_perl list was able to help me I'm filing this bug report and hope that I'm not doing something terribly wrong that's causing these errors to crop up. I have a feeling that it's caused by the global $dbh variable which would be a real problem because our quite large (and somewhat outdated) Mason application relies on this :(
MIME-Version: 1.0
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Disposition: inline
Charset: utf8
Message-Id: <rt-3.6.HEAD-8108-1214899235-186.37272-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 251
Download (untitled) / with headers
text/plain 251b
Just for the record: I'm using a MySQL 5.0.51a binary from mysql.com, a hand-rolled Apache 1.3.41 with mod_perl/1.30 and DBI 1.605, DBD::mysql 4.004 (4.007 causes segfaults on my system) and Apache::DBI 1.07 on a Ubuntu 8.04 system with kernel 2.6.24.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Disposition: inline
Charset: utf8
Message-Id: <rt-3.6.HEAD-8123-1214921325-720.37272-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 480
Download (untitled) / with headers
text/plain 480b
Here's the $Apache::DBI::DEBUG output: On server start: ---------------- 20097 Apache::DBI skipping connection during server startup, read the docu !! 20097 Apache::DBI push PerlCleanupHandler 20097 Apache::DBI need ping: yes 20097 Apache::DBI new connect to 'foo:bar...' 20097 Apache::DBI disconnect (overloaded) On first request: ---------------- 20099 Apache::DBI need ping: yes 20099 Apache::DBI already connected to 'foo:bar...' 20099 Apache::DBI PerlCleanupHandler
MIME-Version: 1.0
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Disposition: inline
Charset: utf8
Message-Id: <rt-3.6.HEAD-20553-1215070494-593.37272-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 306
Download (untitled) / with headers
text/plain 306b
As Perrin Harkins suggested on the mod_perl mailing list, replacing PerlModule LostHandler with <Perl> use LostHandler; </Perl> fixes the issue. The exact cause of the problem still remains unknown. Because we still don't know if this is a bug in MP1 and/or Apache::DBI I'm keeping this ticket open.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.