[ZODB-Dev] Zeo server error message
Hello, I have a customer who run a ZEO setup with ZODB 3.8.4. They report this error: 2011-01-31T12:02:24 Unexpected error Traceback (most recent call last): File "/opt/zope/newbuildout/parts/zope2/lib/python/ZODB/ConflictResolution.py", line 207, in tryToResolveConflict resolved = resolve(old, committed, newstate) File "/opt/zope/newbuildout/parts/zope2/lib/python/ZODB/ConflictResolution.py", line 141, in __cmp__ raise ValueError( ValueError: can't reliably compare against different PersistentReferences Does anyone know to what this error relate ? They have been running their ZEO setup for quite a while, and never experienced any issue. That doesn't seems to 'break' the database either. I am not really sure what to say about this error. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ 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, history-free, pack causes POSKeyError with BTreeFolder2
On 28/01/2011 21:58, Jürgen Herrmann wrote: > Afaics you use zodbpack's default of "days=0". This is known to produce > POSKeyErrors if the database is written to while packing. Where is this documented? Does this apply to history-keeping or history-free storages? > Try with > something > like days=0.1 . I'll not pack a history-free storage until Shane gives it the okay... However, I find it a bit odd that RelStorage ships with a default that could cause these kind of problems and no warning in the readme that this is the case... 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, history-free, pack causes POSKeyError with BTreeFolder2
On 01/31/2011 06:02 PM, Chris Withers wrote: > On 28/01/2011 21:58, Jürgen Herrmann wrote: >>Afaics you use zodbpack's default of "days=0". This is known to produce >>POSKeyErrors if the database is written to while packing. > > Where is this documented? It is not known to me. :-) > I'll not pack a history-free storage until Shane gives it the okay... Good, because although I fixed a bug your test revealed, your test still fails, and I don't yet know why. :-( 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] Zeo server error message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2011 07:27 AM, Sylvain Viollon wrote: > Hello, > > I have a customer who run a ZEO setup with ZODB 3.8.4. They report > this error: > > 2011-01-31T12:02:24 Unexpected error > Traceback (most recent call last): > File > "/opt/zope/newbuildout/parts/zope2/lib/python/ZODB/ConflictResolution.py", > line 207, in tryToResolveConflict > resolved = resolve(old, committed, newstate) > File > "/opt/zope/newbuildout/parts/zope2/lib/python/ZODB/ConflictResolution.py", > line 141, in __cmp__ > raise ValueError( > ValueError: can't reliably compare against different > PersistentReferences > > Does anyone know to what this error relate ? > > They have been running their ZEO setup for quite a while, and never > experienced any issue. That doesn't seems to 'break' the database either. > > I am not really sure what to say about this error. I believe this is a real bug: the PersistentReference class is raising a ValueError becuase the object being compared is not itself, which implies an irresolvable conflict: it should be raising ConflictError, or else a custom error which would be caught by 'tryToResolveConflict' and converted into a ConflictError. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1G4aYACgkQ+gerLs4ltQ7LMQCdG1u1RF2kWZbhkgwkBbfKTkNy U9wAoMYQ0Tv/SgiXNlCxuUDZaJWjWAnU =PH8G -END PGP SIGNATURE- ___ 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] Error from MySQL when attempting to run zodbconvert
Hi Shane, I got the following error when trying to run zodbconvert against a clustered MySQL environment running RHCS: File "/var/buildout-eggs/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/connections.py", line 36, in defaulterrorhandler raise errorclass, errorvalue _mysql_exceptions.OperationalError: (1598, "Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'") Any ideas? 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] Error from MySQL when attempting to run zodbconvert
On 31/01/2011 16:30, Chris Withers wrote: > I got the following error when trying to run zodbconvert against a > clustered MySQL environment running RHCS: > > File > "/var/buildout-eggs/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/connections.py", > line 36, in defaulterrorhandler > raise errorclass, errorvalue > _mysql_exceptions.OperationalError: (1598, "Binary logging not possible. > Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for > binlog mode 'STATEMENT'") I fixed this by setting binlog-format to MIXED rather than STATEMENT in my.cnf. There don't appear to be any downsides to this, so maybe this should go in the docs somewhere? 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, history-free, pack causes POSKeyError with BTreeFolder2
On Fri, Jan 28, 2011 at 4:58 PM, Jürgen Herrmann wrote: ... > Afaics you use zodbpack's default of "days=0". This is known to produce > POSKeyErrors if the database is written to while packing. It can lead to POSKeyErrors under certain pathological cases, but Is not generally a problem in practice. An example where it could be a problem: x = Foo() self._p_jar.add(x) transaction.commit() At this point, x is in the database and is thus garbage. For the sake of this discussion, assume the database is packed to this point in time and x is removed from the database. self.x = x transaction.commit() At this point, self refers to an object that is no longer in the db. At some later time, once self has been ghostified and x is removed from local cache, if we try to access x, we'll get a poskey error. I would argue that the application code above is broken. Note that the storage could validate the reference to x when self is saved, but no storage that I know of does, for performance reasons. In some future version of ZODB, it might be nice to change the database record structure to make this sort of check easier. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] bug with RelStorage's zodbconvert --clear when clearing a large DB with MySQL
Hi Shane, This one's less serious if it is what I think it is: Traceback (most recent call last): File "bin/zodbconvert", line 24, in relstorage.zodbconvert.main() File "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/zodbconvert.py", line 89, in main destination.zap_all() File "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/storage.py", line 308, in zap_all self._rollback_load_connection() File "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/storage.py", line 217, in _rollback_load_connection self._load_conn.rollback() _mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away') 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. Still, far from 100% on that but thought I'd let you know. 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? 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] Error from MySQL when attempting to run zodbconvert
On 01/31/2011 06:30 PM, Chris Withers wrote: > Hi Shane, > > I got the following error when trying to run zodbconvert against a > clustered MySQL environment running RHCS: > > File > "/var/buildout-eggs/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/connections.py", > line 36, in defaulterrorhandler > raise errorclass, errorvalue > _mysql_exceptions.OperationalError: (1598, "Binary logging not possible. > Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for > binlog mode 'STATEMENT'") That's why you have to use row-based replication instead of statement-based replication. 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] bug with RelStorage's zodbconvert --clear when clearing a large DB with MySQL
On 02/01/2011 12:19 AM, Chris Withers wrote: > Hi Shane, > > This one's less serious if it is what I think it is: > > Traceback (most recent call last): > File "bin/zodbconvert", line 24, in > relstorage.zodbconvert.main() > File > "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/zodbconvert.py", > line 89, in main > destination.zap_all() > File > "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/storage.py", > line 308, in zap_all > self._rollback_load_connection() > File > "/var/buildout-eggs/RelStorage-1.4.0-py2.6.egg/relstorage/storage.py", > line 217, in _rollback_load_connection > self._load_conn.rollback() > _mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away') > > 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. That is a bad idea IMHO, so I think raising that exception is the right thing to do, not a bug. > 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. 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
