[Zope-dev] Zope Tests: 74 OK, 31 Failed, 2 Unknown
Summary of messages to the zope-tests list. Period Tue Jan 11 12:00:00 2011 UTC to Wed Jan 12 12:00:00 2011 UTC. There were 107 messages: 8 from Zope Tests, 2 from buildbot at pov.lt, 22 from buildbot at winbot.zope.org, 8 from ccomb at free.fr, 67 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 09:43:20 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028427.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 09:45:02 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028432.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 14:44:39 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028440.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 14:51:29 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028444.html Subject: FAILED : winbot / ztk_dev py_254_win32 From: buildbot at winbot.zope.org Date: Tue Jan 11 15:18:56 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028448.html Subject: FAILED : winbot / ztk_dev py_265_win32 From: buildbot at winbot.zope.org Date: Tue Jan 11 15:27:25 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028449.html Subject: FAILED : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Tue Jan 11 15:35:46 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028450.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:42:05 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028451.html Subject: FAILED : winbot / ztk_dev py_270_win32 From: buildbot at winbot.zope.org Date: Tue Jan 11 15:44:36 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028452.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:46:05 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028453.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:46:44 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028454.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:48:37 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028455.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:50:38 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028456.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:51:47 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028457.html Subject: FAILED : winbot / ztk_dev py_270_win64 From: buildbot at winbot.zope.org Date: Tue Jan 11 15:53:07 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028458.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.6 slave-osx From: jdriessen at thehealthagency.com Date: Tue Jan 11 15:54:33 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028459.html Subject: FAILED : winbot / ztk_10 py_244_win32 From: buildbot at winbot.zope.org Date: Tue Jan 11 16:02:29 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028460.html Subject: FAILED : Zope Buildbot / zopetoolkit-py2.5 slave-osx From: jdriessen at thehealthagency.com Date: Tue Jan 11 16:07:30 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028461.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 20:28:35 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028474.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 20:29:48 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028475.html Subject: FAILED : winbot / z3c.rml_py_265_32 From: buildbot at winbot.zope.org Date: Tue Jan 11 21:20:29 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028486.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.5 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 21:22:27 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028488.html Subject: FAILED : Zope Buildbot / zopetoolkit_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Tue Jan 11 21:28:57 EST 2011 URL:
[Zope-dev] ConnectionStateError
Hello, We have been experiencing some ConnectionStateError in a Zope 2 based application. Looking for info on the web makes me almost 100% sure that we have a bug in our application layer. I understand that I should look for persistent objects stored in module or class level variables (which imply shared by threads and thus connections). Do not hesitate to tell me if this is a wrong explanation of the potential cause of ConnectionStateError. However, I wonder if some of you could give debugging techniques outside reviewing the code. I also wonder what was the reason to deprecate ``zope.thread``. I see it was used by ``zope.component`` to hold thread-safe siteinfo. Could a too frequent usage of getSite lead to ConnectionStateError ? I think that it is not the case but I prefer to ask. Thanks -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ConnectionStateError
On Wed, Jan 12, 2011 at 02:34:13PM +0100, Godefroid Chapelle wrote: We have been experiencing some ConnectionStateError in a Zope 2 based application. Looking for info on the web makes me almost 100% sure that we have a bug in our application layer. I understand that I should look for persistent objects stored in module or class level variables (which imply shared by threads and thus connections). Do not hesitate to tell me if this is a wrong explanation of the potential cause of ConnectionStateError. However, I wonder if some of you could give debugging techniques outside reviewing the code. I would be inclined to use pdb, get hold of the offending object, and then use http://mg.pov.lt/objgraph/ to find which global variable refers to it. (It could be a case of if all you've got is a hammer, since objgraph is still shiny in my mind.) I also wonder what was the reason to deprecate ``zope.thread``. Because it was folded into the standard library in Python 2.4. zope.thread.local() became threading.local() I see it was used by ``zope.component`` to hold thread-safe siteinfo. Could a too frequent usage of getSite lead to ConnectionStateError ? I think that it is not the case but I prefer to ask. Unlikely. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ConnectionStateError
We have been experiencing some ConnectionStateError in a Zope 2 based application. Looking for info on the web makes me almost 100% sure that we have a bug in our application layer. I understand that I should look for persistent objects stored in module or class level variables (which imply shared by threads and thus connections). Do not hesitate to tell me if this is a wrong explanation of the potential cause of ConnectionStateError. I've experienced this error, and that was indeed the cause. IIRC, in the case of the app I was dealing with at the time, it had managed to register a persistent object as a utility - and so ended up in the situation where the application tried to load the object using the wrong database connection. The moral of the story here is that there are more places than just module level globals to look :) It happened some time ago, so I'm afraid I cannot recall how we debugged it (only the amount of facepalming when we did.) I suspect finding out what the type of object was turned out to be a good indicator in our case, as it would only have been used in a couple of places. Cheers, Dan -- Dan Fairs | dan.fa...@gmail.com | www.fezconsulting.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ConnectionStateError
On Wed, Jan 12, 2011 at 2:34 PM, Godefroid Chapelle got...@bubblenet.be wrote: I understand that I should look for persistent objects stored in module or class level variables (which imply shared by threads and thus connections). Do not hesitate to tell me if this is a wrong explanation of the potential cause of ConnectionStateError. However, I wonder if some of you could give debugging techniques outside reviewing the code. Do you get the classic: Shouldn't load state for %s when the connection is closed or one of the The database connection is closed errors? In the first case you get the p_oid, which you can load from the database to give you some clue on what class it is. Typical problems include using plone.memoize decorators on things without knowing where exactly the cache is stored or as someone else noted registering persistent objects in the global site manager instead of the local one. The global one is of course just a module global data structure in the end. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ConnectionStateError
Le 12/01/11 17:06, Hanno Schlichting a écrit : On Wed, Jan 12, 2011 at 2:34 PM, Godefroid Chapellegot...@bubblenet.be wrote: I understand that I should look for persistent objects stored in module or class level variables (which imply shared by threads and thus connections). Do not hesitate to tell me if this is a wrong explanation of the potential cause of ConnectionStateError. However, I wonder if some of you could give debugging techniques outside reviewing the code. Thanks for help from anyone. Once debugged, I'll blog how I found the bug. Do you get the classic: Shouldn't load state for %s when the connection is closed or one of the The database connection is closed errors? In the first case you get the p_oid, which you can load from the database to give you some clue on what class it is. I had no clue that the number in the error message was the p_oid. I could have found out by reading the code. Nevertheless, I propose to make the error message more self-explanatory. Typical problems include using plone.memoize decorators on things without knowing where exactly the cache is stored or as someone else noted registering persistent objects in the global site manager instead of the local one. The global one is of course just a module global data structure in the end. Hanno -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Am 11.01.2011, 22:44 Uhr, schrieb Tres Seaver tsea...@palladion.com: Python 2.5 isn't even getting security fixes from Python devs now, which means that Debian users are holding more risk than they know (I strongly doubt the Debian packagers of Python are up for backporting all the potential security fixes in the 2.6 / 2.7 lines). I understand that and I don't understand Debian's policy - maybe after they move to a better kernel (no, don't bite...) they'll start following a better release policy as well? But this was precisely the reason cited for keeping support for 2.5 in the ZTK 1. I find this somewhat contradictory. To the extent that there may well be people out there with existing servers that are dependent upon package management and, therefore, less likely to want to roll their own Python install, this makes sense. So +1 on yuppie's initial suggestion for a 2.12 compatibility marking. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
