Juan David, OK, 1.1.0a3 indeed suffers from the same problem, I'm going to take a closer look the the publishing mechanism to see if I can find anything relevant. Thanks, J.F. -----Original Message----- From: "J. David Ibáñez" [mailto:jdavid@itaapy.com] Sent: May 20, 2004 10:17 AM To: Jean-Francois.Doyon@CCRS.NRCan.gc.ca Cc: tseaver@zope.com; brian@zope.com; chrism@plope.com; zope-dev@zope.org Subject: Re: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors The "a" in 1.1.0a3 means "alpha". If the problem is in Localizer 1.0.1 I think it will be in 1.1.0a3 too. Yes, I have a site with a similar behaviour, unfortunately today the network connection is too slooow, so I can't test that site. I'm going to do some local tests, though. Yes, the problem might be the fact that "new_publish" does not catch exceptions to remove the request from the dictionary. Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:

Juan David,

I'm using 1.0.1 ... I'm just abotu to try and test with 1.1.0a3 ...

BTW, does that mean it's alpha software or something? is 1.1.0 stable?

If the problem comes from Localizer I suspect this patch might be the cause:

def new_publish(request, module_name, after_list, debug=0): id = get_ident() print "Localizer got thread id: " + str(id) Publish._requests[id] = request print "Request dict is now: " + str(Publish._requests) x = Publish.old_publish(request, module_name, after_list, debug) try: del Publish._requests[id] except KeyError: # XXX # Some people has reported that sometimes a KeyError exception is # raised in the previous line, I haven't been able to reproduce it. # This try/except clause seems to work. I'd prefer to understand # what is happening. LOG('Localizer', PROBLEM, "The thread number %s don't has a request object associated." % id) except: print "Localizer got an exception"

return x

What happens if an exception occurs here:

x = Publish.old_publish(request, module_name, after_list, debug)

??

If some clean up code is supposed to occur it might be held back by the fact that there's a reference to the request kept in the global dictionary ... At least that's my theory :) But then I'm mostly uneducated about the intricacies of exception handling at this level, though I've been forced to learn quickly :)

I'd be curious to know at least if you can reproduce the leak by generating loads of errors on a Localizer enabled site?

One option would also be to simply wrap it in a try:catch and see what happens there ... But I noticed 1.1.0a3 uses a different model for wrapping the request, so that just might do the trick.

Thanks for a very cool and useful product BTW. This is combination with the TranslationService is saving me loads of time.

Cheers, J.F.

-----Original Message----- From: zope-dev-bounces@zope.org [mailto:zope-dev-bounces@zope.org]On Behalf Of "J. David Ibáñez" Sent: May 20, 2004 6:47 AM To: Tres Seaver Cc: Jean-Francois.Doyon@ccrs.nrcan.gc.ca; brian@zope.com; chrism@plope.com; zope-dev@zope.org Subject: [Zope-dev] Re: Preliminary findings: Zope 2.7 leakage caused by errors

Localizer (1.0.1) dynamically patches Zope, it stores a dictionary in the module "ZPublisher.Publish". The keys are integers, they are the values returned by Python's "thread.get_ident". The values are "ZPublisher.HTTPRequest.HTTPRequest" instances, they are not acquisition wrappers.

Jean-François, which Localizer version do you use? Just to be sure we look at the same code.

-- J. David Ibáñez Founder and CTO of Itaapy <http://www.itaapy.com> 9 rue Darwin, 75018 Paris Tel +33 (0)1 42 23 67 45 / Fax +33 (0)1 53 28 27 88