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