Odd timeouts talking to MySQL 4.0, but not 3.x

Odd timeouts talking to MySQL 4.0, but not 3.x

am 17.02.2004 17:10:56 von Tim Cutts

I note that this was discussed in November, and Rudy asked for some
example code which demonstrates the problem. Here is some from my
site, where we are seeing the same problem (dropped connections after 8
hours):

use strict;
use DBI;

print "Connecting\n";
my $db =
DBI->connect("DBI:mysql:database=blahblah;host=xxxx;port=nnn n",
"someone",
"secret",
{RaiseError => 1});

die "Could not connect" unless (defined($db));

sleep(30000);

eval {
# I imagine any valid SQL for your database will work here
my $st = $db->prepare("select count(*) from contig");
$st->execute;
my $res = $st->fetchrow_arrayref;
if ($res) {
printf "Rows in contig (after long connection) = %d\n",
$res->[0];
}
};

$@ and die "Could not get data because: '$@\n";

$db->disconnect;

Server: 4.0.14 running on AlphaServer ES45, Tru64 5.1B

Client: perl 5.8.0
$DBI::VERSION = 1.37
$DBD::mysql::VERSION = 2.9002
Clients running on both Linux and Alpha machines.

Here are all the timeout variables on the instance in question:

>show variables like '%timeout';
+--------------------------+--------+
| Variable_name | Value |
+--------------------------+--------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_lock_wait_timeout | 50 |
| interactive_timeout | 267820 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| wait_timeout | 267820 |
+--------------------------+--------+
8 rows in set (0.02 sec)

so there shouldn't be a timeout after 8 hours of activity...

and packet size is nice and large:

>show variables like '%packet';
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16776192 |
+--------------------+----------+

If the same client connects to a MySQL 3.x instance, the timeout does
not occur, and everything works. Unsurprisingly, the users are
beginning to be reluctant to move to MySQL 4...

Does anyone have any other views as to what on earth is going on here?

Thanks...

Tim

--
Dr Tim Cutts
Informatics Systems Group
Wellcome Trust Sanger Institute
Hinxton, Cambridge, CB10 1SA, UK


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org