Help! Zope is hanging - Issue 852 in collector?
Hi, I am new to this group, so please forgive me if this problem has been addressed in the past. I was not able to find any solution on Google or elsewhere. I am running Zope, MySQL and Plone and occasionally Zope will lockup under load. Below is the messages from the log: 2003-06-18T14: 06:31 ERROR(200) ZODB A storage error occurred during transaction abort. This shouldn't happen. Traceback (innermost last): File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 261, in commit File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 392, in _commit_error AttributeError: Surrogate instance has no attribute '_p_oid' ------ 2003-06-18T14: 06:31 ERROR(200) SiteError http://xxx/mail_password Traceback (innermost last): File /xxx/2-6-1/lib/python/ZPublisher/Publish.py, line 102, in publish File /xxx/2-6-1/lib/python/Zope/App/startup.py, line 200, in commit File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 261, in commit File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 392, in _commit_error AttributeError: Surrogate instance has no attribute '_p_oid' It happens within any ZPT, not only mail_password. After this occurs zope locks up within a minute or so. We have been getting this almost daily, and need to restart Zope when it happens. I found an unresolved issue in the zope collector ( http://collector.zope.org/Zope/852 ) which seems to be the same problem. I have found several work arounds: 1) Apparently a work around is to run Zope 2-6-0 instead of 2-6-1 . 2) Setup the tables in MySQL to support transactions. Currently our MySQL tables are not enabled for transactions. Does anyone else have experience with this issue? I have a rather large installation and am reluctant to roll back to 2-6-0 :( -- Craig Funk PanTechnica Corporation
Craig Funk wrote at 2003-7-11 09:34 -0500:
Hi, I am new to this group, so please forgive me if this problem has been addressed in the past. I was not able to find any solution on Google or elsewhere.
I am running Zope, MySQL and Plone and occasionally Zope will lockup under load. Below is the messages from the log:
2003-06-18T14: 06:31 ERROR(200) ZODB A storage error occurred during transaction abort. This shouldn't happen.
Traceback (innermost last):
File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 261, in commit
File /xxx/2-6-1/lib/python/ZODB/Transaction.py, line 392, in _commit_error
AttributeError: Surrogate instance has no attribute '_p_oid'
Please search the mailing list archives (for Zope and Zope-Dev) and maybe the (Zope) collector. I remember that this problem has been discussed and I think Toby has had a solution. Dieter
Thanks Dieter, I have searched, and found the many messages relating to this problem...but no fix is provided. the message from Toby: http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/81AB35AB6E46BE42 He mentions that it has been fixed, but does not mention how to get the new fix. Also I found issue 852, which is still pending, in the collector and that workaround was to backout to 2.6.0. Is this the only option? Thanks again. Please search the mailing list archives (for Zope and Zope-Dev) and maybe the (Zope) collector. I remember that this problem has been discussed and I think Toby has had a solution. Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ------ End of Forwarded Message
Craig Funk wrote at 2003-7-11 14:35 -0500:
Thanks Dieter, I have searched, and found the many messages relating to this problem...but no fix is provided. the message from Toby:
http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/81AB35AB6E46BE42
He mentions that it has been fixed, but does not mention how to get the new fix.
I do not know the answer, but all of us have access to Zope's cvs (<http://cvs.zope.org>). I expect, you will find an answer there.
Also I found issue 852, which is still pending, in the collector and that workaround was to backout to 2.6.0. Is this the only option?
I doubt it, but again can not give a definite answer. We are using Zope 2.6.1 and do not have any problems. Dieter
On Sunday 13 July 2003 23:42, Dieter Maurer wrote:
I do not know the answer, but all of us have access to Zope's cvs (<http://cvs.zope.org>). I expect, you will find an answer there.
Zope 2.6.1 had some bugs where ZODB assumed objects that participate in transactions had the normal _p_oid attribute. iirc, it only used this assumption when formatting an error message. I think Shane tweaked that when working on Ape, but it looks like the false assumption is still in the 2.6 branch today. (sorry, I dont have cvs access right now to track down the history)
Also I found issue 852, which is still pending, in the collector and that workaround was to backout to 2.6.0. Is this the only option?
I doubt it, but again can not give a definite answer.
We are using Zope 2.6.1 and do not have any problems.
If your traceback originates inside code that is formatting an error message then, as a quick workaround, you could easily hack that code to remove the _p_oid assumption. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
participants (3)
-
Craig Funk -
Dieter Maurer -
Toby Dickenson