Re: trapping mysql errors

Replies are listed 'Best First'.
Re^2: trapping mysql errors by vancetech (Beadle) on Jul 28, 2006 at 16:43 UTC
I left the process over night and observed the problem where it halts at id #387... after a length of time (hours?) a SIG{ALRM} catches the execute statement. The script loops and $dbh->ping() determines the database is disconnected so it reconnects and hangs again with the same id #387. `61 362 +363 +364 +365 +366 367 368 369 370 371 372 373 374 375 376 377 + 378 379 380 381 382 383 384 385 386 387 Timed out 387 Timed out 387 DB Connected 387 Timed out 387 DB Connected 387 Timed out 387 DB Connected 387 Timed out 387 DB Connected` [download] My main question is: "Why isn't the $SIG{ALRM} catching this hang in a timely manner?" Ok I'm finding that it's possibly a networking issue that is only local to the machine I'm running on. When I use my FQDN as the database host ( which traverses the router ) I get this problem. When I use localhost as the database host, I do not get this problem. If I start the count at 387 it will hang right away including starting at the other numbers I have problems with ( $i == 402 \|\| $i == 553 \|\| $i == 571 \|\| $i == 623 ). From another PC on the same network, I am unable to replicate this error both using the FQDN and the internal IP address of the database server. My DBI trace doesn't show me anything other than that is is hanging on the execute statement: 387 -> ping for DBD::mysql::db (DBI::db=HASH(0x81a75f0)~0x81a6964) <- ping= 1 at ./test.pl line 65 via ./test.pl line 59 -> prepare for DBD::mysql::db (DBI::db=HASH(0x81a75f0)~0x81a6964 ' +SELECT * FROM monitor_list WHERE id = 387 LIMIT 1') dbih_setup_handle(DBI::st=HASH(0x81cd488)=>DBI::st=HASH(0x81cd428) +, DBD::mysql::st, 81cd0c8, Null!) dbih_make_com(DBI::db=HASH(0x81a6964), 81a6c04, DBD::mysql::st, 22 +4, 0) thr#0 dbih_setup_attrib(DBI::st=HASH(0x81cd428), Err, DBI::db=HASH(0x81a +6964)) SCALAR(0x815cdd8) (already defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), State, DBI::db=HASH(0x8 +1a6964)) SCALAR(0x815ce38) (already defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), Errstr, DBI::db=HASH(0x +81a6964)) SCALAR(0x815ce08) (already defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), TraceLevel, DBI::db=HAS +H(0x81a6964)) 15 (already defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), FetchHashKeyName, DBI:: +db=HASH(0x81a6964)) 'NAME' (already defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), HandleSetErr, DBI::db=H +ASH(0x81a6964)) undef (not defined) dbih_setup_attrib(DBI::st=HASH(0x81cd428), HandleError, DBI::db=HA +SH(0x81a6964)) undef (not defined) Setting mysql_use_result to 0 <- prepare= DBI::st=HASH(0x81cd488) at ./test.pl line 65 via ./tes +t.pl line 59 -> execute for DBD::mysql::st (DBI::st=HASH(0x81cd488)~0x81cd428) -> dbd_st_execute for 081a6bc8 -> mysql_st_interal_execute [download] Thanks for your responses, Monks. I couldn't do it without you.	[reply] [d/l] [select]
Re^2: trapping mysql errors by vancetech (Beadle) on Jul 28, 2006 at 17:33 UTC
I am unable to replicate the problem in the mysql monitor. In diagnosing the problem I duplicated the table into a new table and re-ran the program. It now hangs on different ID's. If I delete that ID (and one more it had a problem with) the program runs fine! I have found that the script is actually having problems reading the last column in my table (only when using the FQDN as the database host, and not when using localhost)! If I select EVERY column by name instead of '*' and omit the last column in the table, the script runs normally. The column is a varchar(22) and doesn't matter what I alter it to be. What could possibly be happening here? I'd think it points to table corruption, but any checks I run on the table come up fine.	[reply]