Hi there,

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 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?



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to