On 2009-09-08, <g...@vmgump.apache.org> wrote:

> Failed to build project #[(704, 704)] : [test-ant], state:Failed
> SQL Warning:<class '_mysql_exceptions.OperationalError'>:(2006, 'MySQL server 
> has gone away')

We keep getting this since a few weeks over and over again.  I guess it
started when somebody upgraded vmgump's OS (many thanks for that!) and
either a newer MySQL or python-mysqldb isn't working as expected.

What I can tell by now is that the database is still there (executed a
few minutes after the emial arrived):

| r...@vmgump:/var/log# /etc/init.d/mysql status
|  * /usr/bin/mysqladmin  Ver 8.41 Distrib 5.0.51a, for debian-linux-gnu on i486
| Copyright (C) 2000-2006 MySQL AB
| This software comes with ABSOLUTELY NO WARRANTY. This is free software,
| and you are welcome to modify and redistribute it under the GPL license
| Server version          5.0.51a-3ubuntu5.4
| Protocol version        10
| Connection              Localhost via UNIX socket
| UNIX socket             /var/run/mysqld/mysqld.sock
| Uptime:                 1 day 23 hours 11 min 10 sec
| Threads: 1  Questions: 6286  Slow queries: 0  Opens: 34  Flush tables: 1  
Open tables: 28  Queries per second avg: 0.037

and hasn't restarted during the Gump run.

<http://dev.mysql.com/doc/refman/5.0/en/gone-away.html> hints at various
reasons why this might happen.  The server side timeout is at eight
hours and we shouldn't be hitting that.

It seems as if the python wrapper was not enabling automatic reconnect
and unfortunately the python-mysqldb version installed by hardy (1.2.2)
doesn't have the ping(reconnect) method later versions have added (by
looking through python-mysqldb's svn logs, that is),

mysql error logs don't say anything (or I just don't find them, quite

My next step would be to wrap each execute() going against the database
in a try/catch that clears the connection and creates a new one if an 
OperationalError is caught.  But before I get my feet wet with another
area of Python I've never used, maybe anybody knows of a better

BTW, after this type of error occurs we get Gump runs where bcel and
many other "early building mvn projects" fail.  This is because the mvn
proxy of the previous run is still up and thinks it could serve
commons-lang but the jar has already been removed by the sync operation
(and thus mvn fails because it cannot download commons-lang).  This
needs to be fixed in a separate way, either by making sure the mvn proxy
is shut down at the end or by clearing it at the start (the later is
probably easier to implement).


To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Reply via email to