Re: [ZODB-Dev] RelStorage and MySQL wait-timeout
On 01/02/2011 18:11, Shane Hathaway wrote: > On 02/01/2011 07:51 PM, Chris Withers wrote: >> I can understand the problem being fairly terminal if there was a >> disconnect *during* a timeout, and I'd expect an exception, but not a >> segfault ;-) > > I haven't seen segfaults except when the dynamic linker used an > incorrect library. Use "ldd" to check the .so files generated during > buildout. Surely these would occur all the time? I've only seen them occur on two occasions, and the same buildouts have worked fine the rest of the time... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] RelStorage and MySQL wait-timeout
On 02/01/2011 07:51 PM, Chris Withers wrote: > I can understand the problem being fairly terminal if there was a > disconnect *during* a timeout, and I'd expect an exception, but not a > segfault ;-) I haven't seen segfaults except when the dynamic linker used an incorrect library. Use "ldd" to check the .so files generated during buildout. Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] RelStorage and MySQL wait-timeout
Hi Shane, On 01/02/2011 17:45, Shane Hathaway wrote: > On 02/01/2011 10:01 AM, Chris Withers wrote: >> 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. > > Random disconnects are unacceptable for RelStorage. If MySQL goes away > outside transaction boundaries, we *have* to propagate the exception to > the application; Are you sure you mean outside? Surely outside is fine, you just reconnect as part of starting the transaction? > otherwise consistency is lost. We can only reconnect at > the next request or transaction boundary. Indeed, and am I right in thinking RelStorage does this just fine, along with emitting a warning message to say that it has occurred? I can understand the problem being fairly terminal if there was a disconnect *during* a timeout, and I'd expect an exception, but not a segfault ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] RelStorage and MySQL wait-timeout
On 02/01/2011 10:01 AM, Chris Withers wrote: > 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. Random disconnects are unacceptable for RelStorage. If MySQL goes away outside transaction boundaries, we *have* to propagate the exception to the application; otherwise consistency is lost. We can only reconnect at the next request or transaction boundary. > (Mike Bayer could probably shed some light given the connection pool > stuff that SQLAlchemy does to deal with MySQL's behaviour...) Unfortunately, the generic behavior implemented by SQLAlchemy would not work here. It would scramble ZODB. Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] RelStorage and MySQL wait-timeout
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 ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev