Hi, I'm investigating some nasty hangs/freezes that seem to occur every 2-3 days. Usually, i just "service zope restart" and I'm back in business. So I turned on event logging on the last restart to help figure this out and Zope hasn't hung yet, but I've been seeing these nasty looking errors (esp. "This shouldn't happen") any ideas, hints, debugging paths that might shed some light on this error would be greatly appreciated!!! thanks, io --- <snip from Zope event log> ------ 2005-01-24T01:00:33 ERROR(200) ZODB A storage error occured during object abort. This shouldn't happen. Traceback (innermost last): File /var/local/zope-2.6.4/lib/python/ZODB/Transaction.py, line 401, in _commit_error File /var/local/zope-2.6.4/lib/python/Shared/DC/ZRDB/TM.py, line 60, in abort File /var/local/zope/lib/python/Products/ZMySQLDA/db.py, line 405, in _abort
iroro wrote:
any ideas, hints, debugging paths that might shed some light on this error would be greatly appreciated!!!
Looks like the MySQL connection is your problem. Is there a chance your Zope server is loosign communication with your MySQL server? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, 24 Jan 2005 19:06:24 -0800 (PST), iroro <iroro@neurobs.com> wrote:
--- <snip from Zope event log> ------
2005-01-24T01:00:33 ERROR(200) ZODB A storage error occured during object abort. This shouldn't happen. Traceback (innermost last): File /var/local/zope-2.6.4/lib/python/ZODB/Transaction.py, line 401, in _commit_error File /var/local/zope-2.6.4/lib/python/Shared/DC/ZRDB/TM.py, line 60, in abort File /var/local/zope/lib/python/Products/ZMySQLDA/db.py, line 405, in _abort
This is almost certainly due to trying to use non-transactional tables. Are you using MySQL with transactions enabled, and are your table types MyISAM or BDB or InnoDB? The latter two support transactions, and as a practical matter, you need transactions to work properly with Zope. -- Computer interfaces should never be made of meat. Using GMail? Setting Reply-to address to <> disables this annoying feature.
participants (3)
-
Andy Dustman -
Chris Withers -
iroro