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
Couldn't load state for 0x11ae03
Traceback (most recent call last):
847, in setstate
897, in _setstate
p, serial = self._storage.load(obj._p_oid, '')
line 448, in load
state, tid_int = cache.load(cursor, oid_int)
line 279, in load
state, tid_int = self.adapter.mover.load_current(cursor, oid_int)
line 125, in mysql_load_current
line 174, in execute
self.errorhandler(self, exc, value)
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...
Simplistix - Content Management, Batch Processing & Python Consulting
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org