[ZODB-Dev] RelStorage and MySQL wait-timeout

[Chris Withers]

On 01/02/2011 04:11, Shane Hathaway wrote:
>> My guess is that the zap_all took so long that the server had gone away
>> by the time the sql statement had be executed.
>
> My guess is MySQL is configured to drop connections when they are idle.

Indeed, Rackspace had configured a wait-timeout of 60 second!
(why on earth they would do that is beyond me, answers on a post card...)

> That is a bad idea IMHO, so I think raising that exception is the right
> thing to do, not a bug.

Okay, but, with it at 60s, I was getting the following behaviour when 
rendering pages:

Couldn't load state for 0x11ae03
Traceback (most recent call last):
   File 
"/var/buildout-eggs/ZODB3-3.9.6-py2.6-linux-i686.egg/ZODB/Connection.py", line 
847, in setstate
     self._setstate(obj)
   File 
"/var/buildout-eggs/ZODB3-3.9.6-py2.6-linux-i686.egg/ZODB/Connection.py", line 
897, in _setstate
     p, serial = self._storage.load(obj._p_oid, '')
   File 
"/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/storage.py", 
line 448, in load
     state, tid_int = cache.load(cursor, oid_int)
   File 
"/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/cache.py", 
line 279, in load
     state, tid_int = self.adapter.mover.load_current(cursor, oid_int)
   File 
"/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/adapters/mover.py", 
line 125, in mysql_load_current
     cursor.execute(stmt, (oid,))
   File 
"/var/buildout-eggs/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/cursors.py", 
line 174, in execute
     self.errorhandler(self, exc, value)
   File 
"/var/buildout-eggs/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/connections.py", 
line 36, in defaulterrorhandler
     raise errorclass, errorvalue
OperationalError: (2006, 'MySQL server has gone away')

...which feels a little on the serious side for (what is for MySQL) 
quite a normal situation to be in.

(Mike Bayer could probably shed some light given the connection pool 
stuff that SQLAlchemy does to deal with MySQL's behaviour...)

>> I also had a segfault trying to do the same conversion which I'm
>> attributing to the MySQL server being restarted by an overeager DBA
>> mid-converstion but still, that shouldn't cause a segfault, right?
>
> I don't know why it would.

I'll let you know if I see it again...

cheers,

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk