Weird ConflictErrors on startup
Hi, I'm trying to move a project from Zope 2.3.2 to Zope 2.4.0. Once I move to 2.4.0, I get lots of the following errors on startup: 2001-08-06T11:32:26 ERROR(200) Zope Couldn't install Membership Traceback (innermost last): File /usr/local/zope/2.4.0_base/lib/python/OFS/Application.py, line 713, in install_product (Object: ApplicationDefaultPermissions) (Info: Membership) File /usr/local/zope/2.4.0_base/lib/python/ZODB/Transaction.py, line 302, in commit File /usr/local/zope/2.4.0_base/lib/python/ZODB/Connection.py, line 420, in commit (Info: (('App.Product', 'Product'), '\x00\x00\x00\x00\x00\x85\x0e\xb5', '')) File /usr/local/zope/2.4.0_base/lib/python/ZODB/FileStorage.py, line 663, in store (Object: dev/var/Data.fs) ConflictError: ('\x00\x00\x00\x00\x00\x00\x00\x00', '\x03>9\xad\xbf;\xcbD') The complete list of these errors, in order, is: LoginManager Membership PlugIns PythonScripts StandardCacheManagers ZPatterns ...they all report the same identical ConflictError, including the OID-y bits. I'd love to know what's going on here but I'm completely stumped... cheers, Chris
I would forward this to ZODB-Dev, perhaps it would help. Chris Withers wrote:
Hi,
I'm trying to move a project from Zope 2.3.2 to Zope 2.4.0.
Once I move to 2.4.0, I get lots of the following errors on startup:
2001-08-06T11:32:26 ERROR(200) Zope Couldn't install Membership Traceback (innermost last): File /usr/local/zope/2.4.0_base/lib/python/OFS/Application.py, line 713, in install_product (Object: ApplicationDefaultPermissions) (Info: Membership) File /usr/local/zope/2.4.0_base/lib/python/ZODB/Transaction.py, line 302, in commit File /usr/local/zope/2.4.0_base/lib/python/ZODB/Connection.py, line 420, in commit (Info: (('App.Product', 'Product'), '\x00\x00\x00\x00\x00\x85\x0e\xb5', '')) File /usr/local/zope/2.4.0_base/lib/python/ZODB/FileStorage.py, line 663, in store (Object: dev/var/Data.fs) ConflictError: ('\x00\x00\x00\x00\x00\x00\x00\x00', '\x03>9\xad\xbf;\xcbD')
The complete list of these errors, in order, is:
LoginManager Membership PlugIns PythonScripts StandardCacheManagers ZPatterns
...they all report the same identical ConflictError, including the OID-y bits.
I'd love to know what's going on here but I'm completely stumped...
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """
On Mon, 06 Aug 2001 12:52:12 +0100, Chris Withers <chrisw@nipltd.com> wrote:
Hi,
I'm trying to move a project from Zope 2.3.2 to Zope 2.4.0.
Once I move to 2.4.0, I get lots of the following errors on startup:
ConflictError: ('\x00\x00\x00\x00\x00\x00\x00\x00', '\x03>9\xad\xbf;\xcbD')
I'd love to know what's going on here but I'm completely stumped...
I think Ive seen this before, when Product initialization modifies a persistent object, then causes an exception (ImportError, or whatever). You see these ConflictErrors if a subsequent Product initialization also modifies a persistent object. I guess the transaction in which that first product was initialized was not correctly aborted. Ive not looked at this in detail, since its only a problem if you have broken products. My priority has always been to unbreak them.... Toby Dickenson tdickenson@geminidataloggers.com
It's generally bad form for a Product to try to modify a persistent object at startup. Unless it's an _v_ attribute or something. Toby Dickenson wrote:
On Mon, 06 Aug 2001 12:52:12 +0100, Chris Withers <chrisw@nipltd.com> wrote:
Hi,
I'm trying to move a project from Zope 2.3.2 to Zope 2.4.0.
Once I move to 2.4.0, I get lots of the following errors on startup:
ConflictError: ('\x00\x00\x00\x00\x00\x00\x00\x00', '\x03>9\xad\xbf;\xcbD')
I'd love to know what's going on here but I'm completely stumped...
I think Ive seen this before, when Product initialization modifies a persistent object, then causes an exception (ImportError, or whatever). You see these ConflictErrors if a subsequent Product initialization also modifies a persistent object.
I guess the transaction in which that first product was initialized was not correctly aborted.
Ive not looked at this in detail, since its only a problem if you have broken products. My priority has always been to unbreak them....
Toby Dickenson tdickenson@geminidataloggers.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """
I think Ive seen this before, when Product initialization modifies a persistent object, then causes an exception (ImportError, or whatever). You see these ConflictErrors if a subsequent Product initialization also modifies a persistent object.
Hmmm... bit strange that going into /var and doing an rm * and then starting Zope proved a very effective way of eradicating this problem. Sadly it also removes all your data ;-)
I guess the transaction in which that first product was initialized was not correctly aborted.
Is that likely to be a Zope bug?
Ive not looked at this in detail, since its only a problem if you have broken products. My priority has always been to unbreak them....
Well, to my knowledge, none of the products were broken, so... cheers, Chris
Toby Dickenson wrote:
I think Ive seen this before, when Product initialization modifies a persistent object, then causes an exception (ImportError, or whatever). You see these ConflictErrors if a subsequent Product initialization also modifies a persistent object.
Ah, okay... So, how do you find out what the error causing the problem is? (the ImportError in your example) The only things showing up in the stupid log file are the ConflictErrors :-(
I guess the transaction in which that first product was initialized was not correctly aborted.
Where and how should it have been aborted? I gotta say, I've never experienced this with broken products before on 2.4.0, and starting with a blank Data.fs does seem to solve the problem. The trouble is that I need the data from _this_ Data.fs :-S Any ideas? cheers, Chris
participants (3)
-
Chris McDonough -
Chris Withers -
Toby Dickenson