J Cameron Cooper wrote:
but we have that fix in our Zope 2.9.8:
Are you absolutely sure you're using a version of Zope with my patches
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
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
Any results from this?
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -