[ZODB-Dev] Zeo server error message

2011-01-31 Thread Sylvain Viollon
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

2011-01-31 Thread Chris Withers
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

2011-01-31 Thread Shane Hathaway
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

2011-01-31 Thread Tres Seaver
-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 Designhttp://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


Re: [ZODB-Dev] Error from MySQL when attempting to run zodbconvert

2011-01-31 Thread Chris Withers
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] Error from MySQL when attempting to run zodbconvert

2011-01-31 Thread Shane Hathaway
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

2011-01-31 Thread Shane Hathaway
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, inmodule
   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