Jerome hebert writes:
... Zope consumes too much memory ... One possibility I see is that the problem is coming from my external methods.
I have an external method doing SOAP request (using the SOAP.py module) and I use a dump python class around the returned SOAP objects to avoid the problem of security exception when accessing the SOAP objects in DTML.
Possibly the SOAP objects are never destroyed by Zope and this would explain why Zope continuously grows in memory. Usually, Python uses reference counting to release objects which are no longer referenced. That works quite reliably, even for objects created in External Methods (no difference wherever the object is created).
However, reference counting is unable to release circular structures. Since Python 2.0, there is a cyclic garbage collector to detect and free circular garbage. For security reasons, this collector does not release cycles where an object has a "__del__" method (see c.l.p for the reasons). Folklore tells that the cyclic garbage collector is also unable to release "ExtensionClass" instances. If this were the case, then you would need to be very careful with almost all special Zope classes (as they probably derive from ExtensionClass). This would mean, if you happen to create circular structures containing an ExtensionClass instance, the cycle would not be freed. There are tools to locate for circular structures. You may also get a hint, when you look at the "Debug management" page in "Control_Panel". Dieter