Re: [ZODB-Dev] Re: More exciting ZODB errors ;-)
Florent Guillaume wrote: The AssertionError makes it back to the user, as it's not a ConflictError. That's a big problem. Oh, you've actually had real user complaints :-/ We haven't yet, but I guess we've just been lucky... If anyone has a means to reproduce these errors, I'd gladly instrument the ZODB code to get to the bottom of it and fix it. Seems like only really high load on the storage server can provoke these... Maybe time for some stress rig? cheers, Chris -- Simplistix - Content Management, Zope & 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 http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: More exciting ZODB errors ;-)
Hallo Florent, Florent Guillaume wrote at 2006-6-26 00:53 +0200: >Dieter Maurer wrote: >> Chris Withers wrote at 2005-12-14 16:23 +: >>> ... >>> File "lib/python/ZODB/Connection.py", line >>> 788, in _setstate_noncurrent >>> assert end is not None >>> AssertionError >> >> This means that the latest modification for this object >> lies before the respective transaction. >> >> In this case, we should not have an invalidation for the object, >> such that we would not call "_setstate_current". >> >> I expect a missing "flush_invalidations" during "Connection._setDB". >> I had to add such a call in our ZODB version: > ... >This patch didn't seem to cure our Zope 2.8 afflicted with the "assert >end is not None" problem. Could you expand a bit on why you think it >would matter? From what I understand of the code, it would only come >into play during a refresh() operation. You are right. My modification only makes refresh safer. >Could you expand on the "it does >more than cache handling"? Invalidations being synchronous, It also resets "connection._invalidated" and "connection._txn_time". >BTW do you have other patches in your local patched ZODB? I'm willing to >look at all of them and see if they can be integrated. Lot's of them (but not related to this problem which I haven't seen so far) -- and not all of them working already. I could make a tarball from the ZODB parts but I doubt that you would be very happy with it... -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: More exciting ZODB errors ;-)
On 26 Jun 2006, at 15:12, Chris Withers wrote: Florent Guillaume wrote: This patch didn't seem to cure our Zope 2.8 afflicted with the "assert end is not None" problem. Florent, Have you actually seen any problems from these errors? I still see them occasionally, but they never seem to have any ill effects, other than leaving me feeling uneasy when I get mailed these kind of errors my MailingLogger... The AssertionError makes it back to the user, as it's not a ConflictError. That's a big problem. If anyone has a means to reproduce these errors, I'd gladly instrument the ZODB code to get to the bottom of it and fix it. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Re: More exciting ZODB errors ;-)
Florent Guillaume wrote: This patch didn't seem to cure our Zope 2.8 afflicted with the "assert end is not None" problem. Florent, Have you actually seen any problems from these errors? I still see them occasionally, but they never seem to have any ill effects, other than leaving me feeling uneasy when I get mailed these kind of errors my MailingLogger... cheers, Chris -- Simplistix - Content Management, Zope & 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 http://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] Re: More exciting ZODB errors ;-)
[old thread from december] Dieter Maurer wrote: Chris Withers wrote at 2005-12-14 16:23 +: ... File "lib/python/ZODB/Connection.py", line 788, in _setstate_noncurrent assert end is not None AssertionError This means that the latest modification for this object lies before the respective transaction. In this case, we should not have an invalidation for the object, such that we would not call "_setstate_current". I expect a missing "flush_invalidations" during "Connection._setDB". I had to add such a call in our ZODB version: def _setDB(self, odb, mvcc=None, txn_mgr=DEPRECATED_ARGUMENT, transaction_manager=None, synch=None): self.transaction_manager = transaction_manager or transaction.manager # DM 2005-08-22: always call '_flush_invalidations' as it does # more than cache handling only self._flush_invalidations() if self._reset_counter != global_reset_counter: # New code is in place. Start a new cache. self._resetCache() # DM 2005-08-22: always call '_flush_invalidations' ##else: ##self._flush_invalidations() Hi Dieter, This patch didn't seem to cure our Zope 2.8 afflicted with the "assert end is not None" problem. Could you expand a bit on why you think it would matter? From what I understand of the code, it would only come into play during a refresh() operation. Could you expand on the "it does more than cache handling"? Invalidations being synchronous, BTW do you have other patches in your local patched ZODB? I'm willing to look at all of them and see if they can be integrated. Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
