when I was cataloging my zope site and was editing i did get a conflict 'competing' writes, which reminded me: how many times does ZOPE try to write to the ZODB and then 'fails' and roll's back - is it 3? assuming this size is configurable where would I go and change this? when i was cataloging i got this: 2000-03:20T03:24:27 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\000\000\350\217' <- this happens right before the competing writes. could someone explain what this \xxx\yyy\zzz is? and how do I redirect ZServer's console to a file? I'm in DOS right now (havent done this in awhile) - and tried to "C:\Program Files\WebSite\bin\python.exe" "C:\Program Files\WebSite\z2.py" -D %1 %2 %3 %4 %5 %6 %7 %8 %9 > C:\temp\zope.log that didnt work.. In linux I've tried redirectings stderr and stdout to a file and i believe it still wouldnt didnt work. thanks, ~alan
On Sun, 19 Mar 2000, alan runyan wrote:
2000-03:20T03:24:27 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\000\000\350\217' <- this happens right before the competing writes. could someone explain what this \xxx\yyy\zzz is?
I believe that is python's octal representation of an internal object index. The 'could not load state' means the ZODB tried to load the object from disk storage and could not complete the operation. I'm getting those on my own database and haven't yet had the time to track down where they are coming from. I fear some sort of database corruption, but so far the system has continued to function despite these errors. --RDM
"R. David Murray" wrote:
On Sun, 19 Mar 2000, alan runyan wrote:
2000-03:20T03:24:27 ERROR(200) ZODB Couldn't load state for '\000\000\000\000\000\000\350\217' <- this happens right before the competing writes. could someone explain what this \xxx\yyy\zzz is?
I believe that is python's octal representation of an internal object index. The 'could not load state' means the ZODB tried to load the object from disk storage and could not complete the operation.
I'm getting those on my own database and haven't yet had the time to track down where they are coming from. I fear some sort of database corruption, but so far the system has continued to function despite these errors.
There error occours because there are pickles in your database that cannot be loaded. The 'persistent' information for an object in the database is a 'pickle', or a serialized representation of the object. In order for the object be loaded into memory the pickle needs to be unwound into an object in memory. However, this serialized representation does *not* contain any active code, it's just the state of the object. In order for the object to truely 'come to life' the pickle must be matched up with the python code that all objects have in one way or another. This error occours when the pickle can be read, but no coresponding python code could be matched up with the object to bring it to life, or, an error occoured while object was being unpickled. Unfortunatly, there aren't any better iagnostic tools to find why these pickles cannot be unloaded, and for the most part they are now orphaned objects, you cannot delete them or manage them or remove them from your database. I can envision some kind of tool like fsck or scandisk that goes through your database (probably offline) and lets you examine/purge/fix these kinds of dead objects. Ty Sarna has come up with an introspectio ntool called the Tranalyser that would probably be a good place to start. -Michel
--RDM
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
participants (3)
-
alan runyan -
Michel Pelletier -
R. David Murray