Hi, First of all, thanks to all the folk who have contributed valuable information to this thread! I did originally increase the pool_size to 20 connections (I'm using ZMySQLDA 1.1.3, patched with MySQLdb 0.1.0; MySQL 3.22.29 on remote host), so I was running Zope with the same number of threads as there were connections, at the time of the hanging. My testing of Zope 2.1.6 is under these same conditions. I think the message of Jim Fulton's to which Michel refers is http://lists.zope.org/pipermail/zope/1999-December/015455.html Lately, I've seen reports of Zope restarting when manage_* is used; just to clarify, in my case Zope is not restarting: a single thread is hanging (deadlocked for some reason, perhaps?). This occurs in manage_* as well as on our live site, but only a single thread is affected at a time (other users could still log in while this thread was in its quiescent state. Michel Pelletier wrote:

I suspect this problem *might* be unrelated to the threadlock discussed so far, in the case of the reported lock, 2 or more threads cause instability. In your case, you report 4 is stable.

Are you referring to the global python threadlock, or the ZODB lock to prevent conflict errors? Writes to ZODB are particularly infrequent, only occurring when I import changes. I'm trying to procure another similar machine for testing; unfortunately my personal machine's hard drive just packed up, so that's no good... If you have *any* suggestions as to where to start debugging (Pavlos Christoforou mentioned the async loop -- is that ZServer/medusa/asyncore.py?), please let me know. I'll start by slowly upping NUMBER_OF_THREADS until something screams. I'm really keen to get to the bottom of this... It's a pity we're about eight hours ahead of you down here in South Africa... Off to try grokking ZServer/*, -- Marcus