Preliminary findings: Zope 2.7 leakage caused by errors
Gents, In following to the discussions regarding the leakage zope.org and my site suffer from, I've done some testing, and here's what I've found. First of all, the leak does seem to occur when errors occur. Unlike what Chris suggested, I still suffer from this leak even when I completely remove standard_error_message. How I tested: I use JMeter, and a 99% identical box, dedicated for testing: - RH 7.3 - Python 2.3.3 compiled with ./configure and no options - Zope 2.7 + a variety of products, both custom and well known (CMF, Localizer, etc ...) I look at my error log on my main site to see the types of errors coming up and note the URL/parameters. Such errors include KeyErrors, a RecursionDepth error, a Method-something-or-other error, and so on. I setup JMeter with multiple concurrent threads and run it. Within minutes I can see refcounts growing abnormally on the test server. I then shut everything down and minimize the caches. The following are left around that shouldn't be: Class May 19, 2004 1:52 pm May 19, 2004 2:26 pm Delta Acquisition.ImplicitAcquirerWrapper 1025 1309 +284 ZServer.HTTPResponse.ZServerHTTPResponse 150 247 +97 ZPublisher.BaseRequest.RequestContainer 146 240 +94 ZPublisher.HTTPRequest.HTTPRequest 172 262 +90 Right now I've focused on finding out why the Requests are still around. Using the gc module, I've found that all leaked requests are being held by a dictionary. If I look at said dictionaries, this is what they might look like: {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {3075: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/maps/peopleandsociety/age/youth/HEAD>, 4100: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>, 5125: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>, 6150: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>, 7175: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/vh_ site/english/maps/archives/5thedition/other/referencemaps>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/misc_/WFSAdapter/sqlmethod.gif>} NOTE: I had to hack the __repr__ of HTTPRequest not to use self['URL'] since it seems that attribute is unavailable in a closed request. I use PATH_INFO instead. Most of the time I get the dictionary with the 'REQUEST' key. Those dictionaries with int's as keys are ones generated by the ExternalMethod I use to run the code to debug ... So even errors raised while trying to debug this leaks a dictionary that holds on to the request(s). Said dictionary does not seem to be referred to by anything, at least not anything the gc module can find (gc.get_referrers()). One possible situation is that said dictionary is actually part of the HTTPRequest, and we have a cyclic reference problem. I don't think so however, I've looked at the HTTPRequest instances, and they have nothing in them other than strings, lists, basic dict's and an HTTPResponse instance. I'll take another look to be sure. Next step is too look at the Wrappers and see what they're all about and what's holding them there. I'm hoping this information might give a clue to someone who knows Zope error handling better than I as to what might be the problem here ... Also I understand zope.org suffers from this? :) Based on this information also, I have no reason to believe this is caused by product code ... I have to guess it's a Zope bug? In some ways this is motivating me to reduce the number of errors that could occur, but because ALL errors seems to cause the problem, I ultimately have no control over it and under certain circumstances I suffer heavily from this. 404's alone probably cause this (I'm plannign to test that explicitely as well). Thoughts, suggestions, comments welcome ... Jean-François Doyon Internet Service Development and Systems Support / Spécialiste de dèveloppements internet et soutien technique Canada Centre for Remote Sensing / Centre Canadien de télédétection Natural Resources Canada / Ressources naturelles Canada http://atlas.gc.ca Tel./Tél. : (613) 992-4902 Fax: (613) 947-2410
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Gents,
In following to the discussions regarding the leakage zope.org and my site suffer from, I've done some testing, and here's what I've found.
First of all, the leak does seem to occur when errors occur. Unlike what Chris suggested, I still suffer from this leak even when I completely remove standard_error_message.
How I tested:
I use JMeter, and a 99% identical box, dedicated for testing:
- RH 7.3 - Python 2.3.3 compiled with ./configure and no options - Zope 2.7 + a variety of products, both custom and well known (CMF, Localizer, etc ...)
I look at my error log on my main site to see the types of errors coming up and note the URL/parameters. Such errors include KeyErrors, a RecursionDepth error, a Method-something-or-other error, and so on.
I setup JMeter with multiple concurrent threads and run it. Within minutes I can see refcounts growing abnormally on the test server.
I then shut everything down and minimize the caches. The following are left around that shouldn't be:
Class May 19, 2004 1:52 pm May 19, 2004 2:26 pm Delta Acquisition.ImplicitAcquirerWrapper 1025 1309 +284 ZServer.HTTPResponse.ZServerHTTPResponse 150 247 +97 ZPublisher.BaseRequest.RequestContainer 146 240 +94 ZPublisher.HTTPRequest.HTTPRequest 172 262 +90
Right now I've focused on finding out why the Requests are still around.
Using the gc module, I've found that all leaked requests are being held by a dictionary. If I look at said dictionaries, this is what they might look like:
{'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>}, {3075: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/maps/peopleandsociety/age/youth/HEAD>, 4100: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>, 5125: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>, 6150: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/english/search/political>, 7175: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/vh_ site/english/maps/archives/5thedition/other/referencemaps>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/debug>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/misc_/WFSAdapter/sqlmethod.gif>}
I know that the Localizer product does (or used to do) some kind of magic to make the REQUEST available to code as a "global". Can you reproduce this data without that product present?
NOTE: I had to hack the __repr__ of HTTPRequest not to use self['URL'] since it seems that attribute is unavailable in a closed request. I use PATH_INFO instead.
Most of the time I get the dictionary with the 'REQUEST' key. Those dictionaries with int's as keys are ones generated by the ExternalMethod I use to run the code to debug ... So even errors raised while trying to debug this leaks a dictionary that holds on to the request(s).
Said dictionary does not seem to be referred to by anything, at least not anything the gc module can find (gc.get_referrers()). One possible situation is that said dictionary is actually part of the HTTPRequest, and we have a cyclic reference problem. I don't think so however, I've looked at the HTTPRequest instances, and they have nothing in them other than strings, lists, basic dict's and an HTTPResponse instance. I'll take another look to be sure.
Again, I would be looking at the Localizer's module-level globals for this one.
Next step is too look at the Wrappers and see what they're all about and what's holding them there.
The wrappers are almost certainly there because the request is holding on to objects, which hold on to others, etc.
I'm hoping this information might give a clue to someone who knows Zope error handling better than I as to what might be the problem here ... Also I understand zope.org suffers from this? :)
Based on this information also, I have no reason to believe this is caused by product code ... I have to guess it's a Zope bug?
In some ways this is motivating me to reduce the number of errors that could occur, but because ALL errors seems to cause the problem, I ultimately have no control over it and under certain circumstances I suffer heavily from this. 404's alone probably cause this (I'm plannign to test that explicitely as well).
Thoughts, suggestions, comments welcome ...
I am CC'ing Juan-David, in case he may be able to offer any insights from the perspective of the Localizer product. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
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. Tres Seaver wrote:
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote:
Gents,
In following to the discussions regarding the leakage zope.org and my site suffer from, I've done some testing, and here's what I've found.
First of all, the leak does seem to occur when errors occur. Unlike what Chris suggested, I still suffer from this leak even when I completely remove standard_error_message.
How I tested:
I use JMeter, and a 99% identical box, dedicated for testing:
- RH 7.3 - Python 2.3.3 compiled with ./configure and no options - Zope 2.7 + a variety of products, both custom and well known (CMF, Localizer, etc ...)
I look at my error log on my main site to see the types of errors coming up and note the URL/parameters. Such errors include KeyErrors, a RecursionDepth error, a Method-something-or-other error, and so on.
I setup JMeter with multiple concurrent threads and run it. Within minutes I can see refcounts growing abnormally on the test server.
I then shut everything down and minimize the caches. The following are left around that shouldn't be:
Class May 19, 2004 1:52 pm May 19, 2004 2:26 pm Delta Acquisition.ImplicitAcquirerWrapper 1025 1309 +284 ZServer.HTTPResponse.ZServerHTTPResponse 150 247 +97 ZPublisher.BaseRequest.RequestContainer 146 240 +94 ZPublisher.HTTPRequest.HTTPRequest 172 262 +90
Right now I've focused on finding out why the Requests are still around.
Using the gc module, I've found that all leaked requests are being held by a dictionary. If I look at said dictionaries, this is what they might look like:
{'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>}, {3075: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/maps/peopleandsociety/age/youth/HEAD>, 4100: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/debug>, 5125: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/debug>, 6150: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/english/search/political>, 7175: <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/vh_
site/english/maps/archives/5thedition/other/referencemaps>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/debug>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh
_site/misc_/WFSAdapter/sqlmethod.gif>}
I know that the Localizer product does (or used to do) some kind of magic to make the REQUEST available to code as a "global". Can you reproduce this data without that product present?
NOTE: I had to hack the __repr__ of HTTPRequest not to use self['URL'] since it seems that attribute is unavailable in a closed request. I use PATH_INFO instead.
Most of the time I get the dictionary with the 'REQUEST' key. Those dictionaries with int's as keys are ones generated by the ExternalMethod I use to run the code to debug ... So even errors raised while trying to debug this leaks a dictionary that holds on to the request(s).
Said dictionary does not seem to be referred to by anything, at least not anything the gc module can find (gc.get_referrers()). One possible situation is that said dictionary is actually part of the HTTPRequest, and we have a cyclic reference problem. I don't think so however, I've looked at the HTTPRequest instances, and they have nothing in them other than strings, lists, basic dict's and an HTTPResponse instance. I'll take another look to be sure.
Again, I would be looking at the Localizer's module-level globals for this one.
Next step is too look at the Wrappers and see what they're all about and what's holding them there.
The wrappers are almost certainly there because the request is holding on to objects, which hold on to others, etc.
I'm hoping this information might give a clue to someone who knows Zope error handling better than I as to what might be the problem here ... Also I understand zope.org suffers from this? :)
Based on this information also, I have no reason to believe this is caused by product code ... I have to guess it's a Zope bug?
In some ways this is motivating me to reduce the number of errors that could occur, but because ALL errors seems to cause the problem, I ultimately have no control over it and under certain circumstances I suffer heavily from this. 404's alone probably cause this (I'm plannign to test that explicitely as well).
Thoughts, suggestions, comments welcome ...
I am CC'ing Juan-David, in case he may be able to offer any insights from the perspective of the Localizer product.
Tres.
-- 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
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote at 2004-5-19 14:44 -0400:
... In following to the discussions regarding the leakage zope.org and my site suffer from, I've done some testing, and here's what I've found.
First of all, the leak does seem to occur when errors occur. Unlike what Chris suggested, I still suffer from this leak even when I completely remove standard_error_message.
I tried to reproduce this behaviour -- but failed. Despite errors and a standard "standard_error_meesage" nothing leaked... -- Dieter
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote at 2004-5-19 14:44 -0400:
... Right now I've focused on finding out why the Requests are still around.
Using the gc module, I've found that all leaked requests are being held by a dictionary. If I look at said dictionaries, this is what they might look like:
{'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot/_vh _site/francais/mapsatoz>},
These dictionaries look like the "instance dict"s of the "ZPublisher.BaseRequest.RequestContainer"s. When you have any cycle involving an AcquisitionWrapper, then its reference to the "RequestContainer" will keep this alive together with its instance dict. You may analyse the content of your requests. Do they contain acquisition wrapped objects (or other objects with (maybe indirect) references to this dict)? If not, "REQUEST" does not seem to be the root of your cycles but rather a side effect. More important notes: * When you see "AcquisitionWrapper"s in the reference information in "Control_Panel --> Debug Information", then there *must* also be other prominent ExtensionClass'es -- the "aq_base" of these wrappers. These classes may provide a valuable clue towards the cause of the cycles -- of global variables (by the way). * The reference information in "Control_Panel" covers only instance objects but not elementary Python data types. Thus, when cycles are caused by elementary Python objects, we may not directly see them in the list. GC's "DEBUG_LEAK" may provide some information. * The leaks may not be caused by cycles at all (though it is the most likely cause) but could result from a global cache containing references to acquisition wrapped objects. Such a cache should never exist -- global variables and class attributes must never directly or indirectly reference persistent objects -- as this results in nasty persistency bugs. Nevertheless, sometimes software is buggy. I noticed such a cache in Archetypes 1.3a2 (fixed in newer versions). ....
Said dictionary does not seem to be referred to by anything, at least not anything the gc module can find (gc.get_referrers()).
That's probably because "RequestContainer" is an ExtensionClass and ExtensionClasses are not yet (only from Zope 2.8 on) GC aware.
... Also I understand zope.org suffers from this? :)
Leaks can have innumerable causes. It is by no means clear that your leak and the one on Zope.org has the same cause.
Based on this information also, I have no reason to believe this is caused by product code ... I have to guess it's a Zope bug?
I do not observe leaks in my Zope installation -- even when I make an error stress test. This does not mean it could not be a Zope bug -- but it implies that such a bug does not surface regularly, at most under special conditions.
In some ways this is motivating me to reduce the number of errors that could occur, but because ALL errors seems to cause the problem, I ultimately have no control over it and under certain circumstances I suffer heavily from this. 404's alone probably cause this (I'm plannign to test that explicitely as well).
It does not here.... Something is special with your installation -- maybe "Localizer" as Tres suggested, maybe another misbehaving product. -- Dieter
I have not followed the discussion but is this leak as serious as it should be resolved before the next 2.7.1 beta1 release? Andreas --On Donnerstag, 20. Mai 2004 9:52 Uhr +0200 Dieter Maurer <dieter@handshake.de> wrote:
Jean-Francois.Doyon@CCRS.NRCan.gc.ca wrote at 2004-5-19 14:44 -0400:
... Right now I've focused on finding out why the Requests are still around.
Using the gc module, I've found that all leaked requests are being held by a dictionary. If I look at said dictionaries, this is what they might look like:
{'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot /_vh _site/francais/mapsatoz>}, {'REQUEST': <HTTPRequest, URL=/VirtualHostBase/http/atlastest2.ccrs.nrcan.gc.ca:80/VirtualHostRoot /_vh _site/francais/mapsatoz>},
These dictionaries look like the "instance dict"s of the "ZPublisher.BaseRequest.RequestContainer"s.
When you have any cycle involving an AcquisitionWrapper, then its reference to the "RequestContainer" will keep this alive together with its instance dict.
You may analyse the content of your requests. Do they contain acquisition wrapped objects (or other objects with (maybe indirect) references to this dict)?
If not, "REQUEST" does not seem to be the root of your cycles but rather a side effect.
More important notes:
* When you see "AcquisitionWrapper"s in the reference information in "Control_Panel --> Debug Information", then there *must* also be other prominent ExtensionClass'es -- the "aq_base" of these wrappers.
These classes may provide a valuable clue towards the cause of the cycles -- of global variables (by the way).
* The reference information in "Control_Panel" covers only instance objects but not elementary Python data types.
Thus, when cycles are caused by elementary Python objects, we may not directly see them in the list.
GC's "DEBUG_LEAK" may provide some information.
* The leaks may not be caused by cycles at all (though it is the most likely cause) but could result from a global cache containing references to acquisition wrapped objects.
Such a cache should never exist -- global variables and class attributes must never directly or indirectly reference persistent objects -- as this results in nasty persistency bugs.
Nevertheless, sometimes software is buggy. I noticed such a cache in Archetypes 1.3a2 (fixed in newer versions).
....
Said dictionary does not seem to be referred to by anything, at least not anything the gc module can find (gc.get_referrers()).
That's probably because "RequestContainer" is an ExtensionClass and ExtensionClasses are not yet (only from Zope 2.8 on) GC aware.
... Also I understand zope.org suffers from this? :)
Leaks can have innumerable causes. It is by no means clear that your leak and the one on Zope.org has the same cause.
Based on this information also, I have no reason to believe this is caused by product code ... I have to guess it's a Zope bug?
I do not observe leaks in my Zope installation -- even when I make an error stress test.
This does not mean it could not be a Zope bug -- but it implies that such a bug does not surface regularly, at most under special conditions.
In some ways this is motivating me to reduce the number of errors that could occur, but because ALL errors seems to cause the problem, I ultimately have no control over it and under certain circumstances I suffer heavily from this. 404's alone probably cause this (I'm plannign to test that explicitely as well).
It does not here....
Something is special with your installation -- maybe "Localizer" as Tres suggested, maybe another misbehaving product.
Andreas Jung wrote at 2004-5-20 10:02 +0200:
I have not followed the discussion but is this leak as serious as it should be resolved before the next 2.7.1 beta1 release?
I doubt that it is a Zope bug... I am unable to reproduce any leak in connection with error handling. Otherwise, we can only answer your question when we know the reason for the leakage. -- Dieter
participants (5)
-
"J. David Ibáñez" -
Andreas Jung -
Dieter Maurer -
Jean-Francois.Doyon＠CCRS.NRCan.gc.ca -
Tres Seaver