[Zope-dev] AW: SVN: zope.app.container/trunk/CHANGES.txt Added release note
Hi Philipp Betreff: Re: SVN: zope.app.container/trunk/CHANGES.txt Added release note [...] I think this it can be released now. The fix you applied was needed either way, if I'm correct. GroupFolder's __init__ was not calling its own super's __init__ but the super __init__ of BTreeFolder. This should have worked before and after the changes in zope.app.container 3.6.x. Yes Of course, it'd be good to test this with both zope.app.container 3.5.x and 3.6.x first :) It works on my old and new projects which uses different container packages. Just released zope.app.authentication 3.4.2 Regards Roger Ineichen _ END OF MESSAGE ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Tue Jul 8 11:00:00 2008 UTC to Wed Jul 9 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Jul 8 21:09:04 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009825.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 8 21:10:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009826.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 8 21:12:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009827.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 8 21:13:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009828.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 8 21:15:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009829.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Dangerous shutdown procedure behaviour
Hi. I think I discovered a dangerous code behaviour at zope shutdown. I've had a strange problem on a site where persistent objects are created from data inserted in an SQL table. Upon object creation, SQL table is updated to mark the line as imported. Such import got triggered just before a shutdown. After restart and another import, documents were created twice. What I believe happened (but I could not find any hard evidence of it) is that Zope blindly exited while the working thread was runing, and in the worst possible method: tpc_finish. ZODB was already commited, but mysql was not. So mysql did a rollback on changes, and the lines were in a ready to import state. And imported again at next import attemp. Reading shutdown code, I discovered 2 distinct timeout mechanism (note: having just one is enough to trigger the problem): - Lifetime.py: iterating through asyncore sockets, it alerts servers that it will shut down soon. If they take the veto for too long, the veto is ignored and shutdown continues. Default timeout is 20 seconds, meaning there is at most one minute from the first shutdown notice to the effective process exit (taking all runing threads down). When invoking zopectl stop, it's runing a fast shutdown, which means the timeout is shortened to 1 second, so total maximum sutdown time is 3 seconds. This timeout can be worked around by just writing blocking shutdown methods and not using the veto system. - zdaemon/zdrun.py: if the instance being shut down still responds after 10 seconds, it will be sent a SIGKILL. This cannot be worked around without changing code in zdrun.py or not executing it at all (no idea if there is any alternative). I could easily reproduce the problem by writing a simple connection mamager which calls time.wait(3600) in _finish method and defining a sortKey method to make it commit after another connection manager. I could not find a trace of any mechanism preventing commit from happening when a shutdown is in progress, and I don't think there should be any: considering that some storages might be accessed through a network, latency can become a problem, so tpc_finish can take time to complete, so just checking that there is no pending shutdown before entering this function would not solve the problem. I suggest removing all those timeouts. If a user wants a Zope to shutdown for a reason serious enough to send it a SIGKILL or causing immediate python thread termination, it's his responsibility. But I think regular shutdown mechanism must not do that. Also, the same problem can happen with zopectl fg since Zope does not go through any shutdown sequence as far as I can tell (it just dies). -- Vincent Pelletier ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.testing releases on PyPI
Hi, the zope.testing releases on PyPI are apparently a bit weird. - zope.testing 3.5.1 has been the latest released version on PyPI last week - I created V 3.5.2 on Sunday. Phillip granted me access to the zope.testing package on PyPI in order to upload 3.5.2 (which worked) - I created V 3.5.3 yesterday morning. Uploading the egg was impossible because I had no longer rights (in fact permissions are currentl only granted to Jim and Fred Drake (not even Phillip) - search for zope.testing on PyPI leads me to version 3.0 instead of 3.5.1 Does anyone know what happened here? Andreas pgp459Jz1XjNk.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] transaction.doom() and ZPublisher
Hi, I noticed that Zope 2.11 includes a recent version of the transaction module including the transaction.doom() method. But I don't see any check for it in ZPublisher. So, if any code calls transaction.doom(), the publisher will raise a user-visible exception when it tries to call commit(). This seems less than useful :-) In the discussion I've seen of this method, eg. https://bugs.launchpad.net/zope3/+bug/98382 and http://markmail.org/message/3yshpmltvhevnrff it sounds like other people share my expectation... namely, that the developer should not have to do anything special after calling transaction.doom(); the transaction is not committed, and the user won't see an exception. Is that the concensus? If so, there's an easy solution - apply something like the attached patch. Anybody disagree? -- Paul Winkler http://www.slinkp.com --- Zope2/App/startup.py~ 2008-06-14 02:50:23.0 -0400 +++ Zope2/App/startup.py2008-07-10 00:08:02.0 -0400 @@ -267,7 +267,8 @@ transaction.begin() def commit(self): -transaction.commit() +if not transaction.isDoomed(): +transaction.commit() def abort(self): transaction.abort() --- ZPublisher/Publish.py~ 2008-06-14 02:50:48.0 -0400 +++ ZPublisher/Publish.py 2008-07-10 00:08:08.0 -0400 @@ -314,7 +314,8 @@ def begin(self): transaction.begin() def commit(self): -transaction.commit() +if not transaction.get().isDoomed(): +transaction.commit() def abort(self): transaction.abort() def recordMetaData(self, object, request): --- ZPublisher/WSGIPublisher.py~2008-06-14 02:50:48.0 -0400 +++ ZPublisher/WSGIPublisher.py 2008-07-09 23:59:57.0 -0400 @@ -401,7 +401,8 @@ def begin(self): transaction.begin() def commit(self): -transaction.commit() +if not transaction.get().isDoomed(): +transaction.commit() def abort(self): transaction.abort() def recordMetaData(self, object, request): ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
