[Zope-dev] Zope Tests: 4 OK, 1 Failed
Summary of messages to the zope-tests list. Period Thu Jan 3 12:00:00 2008 UTC to Fri Jan 4 12:00:00 2008 UTC. There were 5 messages: 5 from Zope Unit Tests. Test failures - Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 3 20:59:50 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008900.html Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 3 20:53:49 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008896.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 3 20:55:19 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008897.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 3 20:56:50 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008898.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 3 20:58:20 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-January/008899.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] Re: five.customerize
Martin Aspeli wrote: Tres Seaver wrote: That said, I suppose this should be either a conditional import or moved to a higher level altogether. - -1 to the conditional import; + 1 to moving the code. Agree. That sounds like the cleanest solution to me too. Any idea on how this will be accomplished? I'm not in an awful hurry, but what's currently released has a dependency on plone.portlets nonetheless and I'd like to have some idea on how to get from where we are to where we need to be. What about the following plan? * the people who made the plone-specific branch check this for any other changes/fixes that are not plone.* specific and if they exist port these to the trunk * we then release a new version of the trunk. Plone 3.0 has locked-down version dependencies, right? It should still retrieve the current version in this case. * the Plone team then can work on moving this code into the right place for future versions of Plone so eventually they can make use of newer releases of five.customerize. Regards, Martijn ___ 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] Re: five.customerize
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Martin Aspeli wrote: Tres Seaver wrote: That said, I suppose this should be either a conditional import or moved to a higher level altogether. - -1 to the conditional import; + 1 to moving the code. Agree. That sounds like the cleanest solution to me too. Any idea on how this will be accomplished? I'm not in an awful hurry, but what's currently released has a dependency on plone.portlets nonetheless and I'd like to have some idea on how to get from where we are to where we need to be. What about the following plan? * the people who made the plone-specific branch check this for any other changes/fixes that are not plone.* specific and if they exist port these to the trunk * we then release a new version of the trunk. Plone 3.0 has locked-down version dependencies, right? It should still retrieve the current version in this case. * the Plone team then can work on moving this code into the right place for future versions of Plone so eventually they can make use of newer releases of five.customerize. It looks to me as though plone.app.customerize should subclass five.customerize.zpt.TTWViewTemplate, and add its support for viewlet / portlet managers to the '__call__' of the subclassed version; the 'register.createTTWViewTemplate' factory could easily use the subclass instead. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHfpCZ+gerLs4ltQ4RAmmHAJ9/7WM1sNmSDqhEIuPjUStMpUET5ACg1rKj 4hiDmSRnNqR0uHnaIX2Bu+I= =D5oW -END 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] KeyError in ZRDB.DA cache handling
On our fairly busy site (http://cnx.org) we're seeing in the logs some
instances of an error in Shared.DC.ZRDB.DA::
...
Module None, line 97, in search_form_handler
- FSPythonScript at /plone/search_form_handler used for
/plone/content
- Line 97
Module Products.RhaptosRepository.Repository, line 537, in
searchRepository
Module Products.RhaptosRepository.VersionFolder, line 456, in search
Module Products.RhaptosModuleStorage.ZSQLFile, line 44, in __call__
Module Shared.DC.ZRDB.DA, line 492, in __call__
- ExtZSQLMethod at /plone/portal_moduledb/20071212233625.240206723892
Module Shared.DC.ZRDB.DA, line 393, in _cached_result
KeyError: (\nSELECT p.*\nFROM persons p\nwhere\n p.firstname ~*
req('href='::text)\n or\n p.surname ~* req('href='::text)\n or\n
p.fullname ~* req('href='::text)\n or \n p.personid ~*
('^'||req('href='::text)||'$')\n or\n p.email ~*
(req('href='::text)||'.*@')\n\n, 0, 'devrep')
This is trying to remove a key from the ZSQL cache to shrink it down to
size, but doesn't find the key. From Shared.DC.ZRDB.DA._cached_result:
# if the cache is too big, we purge entries from it
if len(cache) = max_cache:
keys=tcache.keys()
# We also hoover out any stale entries, as we're
# already doing cache minimisation.
# 'keys' is ordered, so we purge the oldest results
# until the cache is small enough and there are no
# stale entries in it
while keys and (len(keys) = max_cache or keys[0] t):
key=keys[0]
q=tcache[key]
del tcache[key]
del cache[q] # = line 393, with the error
del keys[0]
It looks a lot like:
https://bugs.launchpad.net/zope2/+bug/143805
but we have that fix in our Zope 2.9.8:
http://osdir.com/ml/web.zope.all-cvs/2006-11/msg00150.html
Perhaps it is another high-load leak? I don't think it can be multiple
threads doing cleanup at the same time, unless maybe there's a
transaction commit in there somewhere I don't know about.
Or maybe I'm running into the problem described in the big comment at
the end?::
# When a ZSQL method is handled by one ZPublisher thread twice in
# less time than it takes for time.time() to return a different
# value, the SQL generated is different, then this code will leak
# an entry in 'cache' for each time the ZSQL method generates
# different SQL until time.time() returns a different value.
#
# On Linux, you would need an extremely fast machine under extremely
# high load, making this extremely unlikely. On Windows, this is a
# little more likely, but still unlikely to be a problem.
#
# If it does become a problem, the values of the tcache mapping
# need to be turned into sets of cache keys rather than a single
# cache key.
Would it be unsafe to toss a try/except around the del cache[q] bit on
the theory that it's already deleted, so, hey, why fail? It'd be really
nice to keep this off of users, even with it if does cause a bit of a leak.
I'll probably be setting up some logging to try and characterize this
further, but anybody have any clues?
--jcc
--
Connexions
http://cnx.org
Building Websites with Plone
http://plonebook.packtpub.com
___
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 )
