Hi there,
J Cameron Cooper wrote:
but we have that fix in our Zope 2.9.8:
http://osdir.com/ml/web.zope.all-cvs/2006-11/msg00150.html
Are you absolutely sure you're using a version of Zope with my patches
included?
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.
I'm afraid it's long enough ago that this code was touched that I can't
really comment on this bit :-S
Or maybe I'm running into the problem described in the big comment at
the end?::
Don't think so, this describes a leak, not a cause of exceptions...
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.
Not sure about the try/except, would be better to nail why the key isn't
there... Best bet is to start trying to reproduce this in a unit test,
which can be pretty hard :-S
I'll probably be setting up some logging to try and characterize this
further,
Any results from this?
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
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 )
