Erik Stephens wrote:

Hello,

This is regarding the Zope restarting problem that's been talked about recently. We've tried TONS of different configurations:

Python 2.1.x (with threads and with & without pymalloc) Zope 2.4.x (built wo_pcgi & binary installs) ZMySQLDA (with & without the Kromer patch) MySQLdb (built against the different flavors of Python)

Here's our latest attempt at a stable Zope:

- Python 2.1.2 (with threads and with pymalloc) - Zope 2.4.4b1 (wo_pcgi build) - ZMySQLDA (latest CVS checkout with and without the Kromer patch applied to db.py) - MySQLdb (latest CVS checkout build against Python 2.1.2) - TinyTable product (one of our patches applied) - A customizations product for removing specific restrictions on through-the-web components.

Does anyone know for sure if this is a problem with ZMySQLDA or with Zope?

We've been hearing talk that once 2.4.4 is released, all will be good in the hood. Are we missing the boat somewhere? Can anyone confirm that a similar setup fixed their Zope restart problems?

Are there any magic option values (num threads, disable watchdog) we can be passing to z2.py that might help stop the bleeding?

If it is confirmed that 2.4.4 is still hosed, then what is the recommended course of action? Down-grade to Zope 2.3.3? Cross our fingers and wait? Which is more stable right now, Zope 2.5.0 or Zope 2.4.4?

Thank you, Erik

Try starting with -t 1 (single-threaded mode) and see if that helps. It won't actually hurt your performance very badly unless you are compute or I/O intensive. Andy Dustman has a better fix than mine in the works; he posted something about it on the main Zope list today. BTW, you said in your message above you use --with-pymalloc. That's almost for sure going to cause problems with extension classes. Use --without-pymalloc so that the custom allocator gets left out. -- Matt Kromer Zope Corporation http://www.zope.com/