(RADIATOR) MySQL server has gone away

[Jose Borges Ferreira]

Hi!

I've recently installed a system that's uses a MySQL 5.19 (a cluster) has a
backend. After that i started to have several errors on Radiator , namely
"MySQL server has gone away" ones. After  some tweaking in mysql and no
success i turned to Perl/Radiator and , for debugging, i turned DBI trace on
to level 2 and checked the logs and got this:
    -- DBI::END
    -> disconnect_all for DBD::mysql::dr
(DBI::dr=HASH(0x75efec)~0x7d61a8)
    <- disconnect_all= (not implemented) at DBI.pm line 677
!   -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x7ce74c)~INNER)
&imp_dbh->mysql: 7e3ab8
!   <- DESTROY= undef during global destruction
!   -> DESTROY in DBD::_::common for DBD::mysql::dr
(DBI::dr=HASH(0x7d61a8)~INNER)
!   <- DESTROY= undef during global destruction
    -> ping for DBD::mysql::db
(DBI::db=HASH(0x7d61cc)~0x7ce74c)
    <- ping= '' at SqlDb.pm line 82
    -> prepare for DBD::mysql::db (DBI::db=HASH(0x7d61cc)~0x7ce74c 'select
TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER from RADPOOL where POOL=?
 and STATE=0 order by TIME_STAMP')
dbd_st_prepare calling count_params (counting params
emulation)
    <- prepare= DBI::st=HASH(0x7e4070) at SqlDb.pm line
182
    -> execute for DBD::mysql::st (DBI::st=HASH(0x7e4070)~0xa22098 'pool2')

    -> dbd_st_execute for 007e40b8
---> parse_params with statement select TIME_STAMP, YIADDR, SUBNETMASK,
DNSSERVER from RADPOOL where POOL=? and STATE=0 order by TIME_STAMP nu
m params 1
     parse_params slen 106
( ...)
<--- parse_params
mysql_st_internal_execute
Binding parameters: select TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER from
RADPOOL where POOL='pool2' and STATE=0 order by TIME_STAMP
MySQL server has gone away error 2006 recorded: MySQL server has gone away
    <- dbd_st_execute returning imp_sth->row_num 18446744073709551614
    !! ERROR: 2006 'MySQL server has gone away' (err#0)
    <- execute= undef at SqlDb.pm line 183


I realized then that , for some reason i cant figure out, DBI is ending and
closing all connections.  The object in Radiator array stills has a "valid"
making the current test not trustworthy. I've attached a patch to address
this issue.

Does anybody else has this problem ?

José Borges Ferreira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060422/b627f6c8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SqlDb.pm.patch
Type: application/octet-stream
Size: 1040 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060422/b627f6c8/attachment.obj>