Re: mysql_connect_timeout laughs at me

Hi bbarnett,

mysql_connect_timeout is an option so should be passed in the connection attributes hashref. See the docs for DBD::mysql Class Methods, DBI connect().

    my $dsn = "dbi:mysql:database=db;host=1.1.1.1";

    my $attr = { mysql_connect_timeout => 1 };

    my $dbh = DBI->connect( $dsn, $user, $password, $attr ) or die DBI
+::errstr;
[download]

Since you are using MySQL you may also be interested in mysql_auto_reconnect.

I also recommend RaiseError for the convenience of not having to type a lot of or die clauses.

Hope this helps!

edit: Added info on other options

The way forward always starts with a minimal test.

Comment on Re: mysql_connect_timeout laughs at me Select or Download Code

Replies are listed 'Best First'.
Re^2: mysql_connect_timeout laughs at me by bbarnett (Initiate) on Jan 19, 2017 at 12:33 UTC
Hmm. I tried that before one of my attempts had that in the same hash as raiseerror.., and now that I think on what you said -- it does seem to work. After a bit of a re-write, I realise that my issue seems to be if the DB server is gone, and a query is attempted. Something that can happen between even a DBI PING and QUERY. If that happens, it just hangs in a 'wait' state forever. EG: - I'm connected - I run a query or two - the MySQL server vanishes - I do a prepare and an execute of a query - I get an error, and raiseerror is on... - I get 'execute failed' and it simply hangs forever Just in case, I've also tried with 'or die' at the end of the execute statement. It still hangs. I have a debugging like .. print "BAH"; right after the execute statement, and it is never reached. I've tried wrapping it in an eval, without an eval around it, using connect_cached and connect, using raiseerror or not, the list goes on. Should a query just hang, if it can't reach the server?! I'm guessing 'connect timeout' is only for connect. Yet, I'm getting an error stating lost connection, so why aren't I getting a raisederror, or the die kicking in?! HELP! :P Thanks btw for the prior, at least I have a much better idea of what the issue is... AH. Perl version.. 5.22 So... just to add to this in an edit.... I'm trying alarm right now. It works, and I'm monkeying with it. But, all over the place I see posts about 'don't do alarm, do this', then other places 'don't do THAT, do this instead' then 'perl v$x will segfault with this and.... I guess my question is.. I can't find a complete "This is how to do completely foolproof MySQL handling under perl, for all versions, catching all errors, etc..." anywhere. Maybe I'm Googling the wrong thing. But, any suggestions? Is alarm OK 100% of the time, in every single case?	[reply]
Re^3: mysql_connect_timeout laughs at me by bbarnett (Initiate) on Jan 19, 2017 at 13:29 UTC
Double hmm.... I have my code in an eval. I also have an alarm set. EG, local $SIG{ALRM} = sub {die "SDFSD";}; The alarm is there to catch that weird, forever waiting execute issue. Yet, the die actually dies. The eval doesn't catch it. No code executes after the 'eval'... Every place I look... that's supposed to work. Is there any place that anyone can think of, where it shows an actual, 100% working .. foolproof, catches all errors, never lets the code die, DBI example? If I can get over the hump of catching all errors, and not having code execution hang forever, I can move on from there... Thanks all...	[reply]
Re^4: mysql_connect_timeout laughs at me by Anonymous Monk on Jan 19, 2017 at 15:35 UTC
It might be that the connect timeout doesn't apply in your scenario, since the connection is already established. Are you setting mysql_read_timeout and mysql_write_timeout as mentioned in the DBD::mysql docs? (It's not completely clear what the default values are, but it's not uncommon for drivers to default to 0 and wait forever.)	[reply]