Gabriel Genellina wrote at 2003-3-26 22:27 -0300:
.... Yes, we do close the connection. This is the full fragment:
app = Zope.app() obj = app.restrictedTraverse(path) get_transaction().commit() app._p_jar.close() del app return obj
The server freezes inside the restrictedTraverse call (never returns).
I suspect there is some hidden and rarely exposed locking bug in Zope causing Zope to stop responding to requests due to a deadlock. I dearly would like to locate and fix it. But, I am unable to reproduce the situation reliably. Maybe, your setup provides a way for reproduction. Are you accustomed using a debugger (on C level?). If so, we may be able to sort this out: You need to connect the debugger to your Python process. You need to select the thread responsible for your hanging operation. You look at the stack trace. This will tell you where your thread is waiting. This may be waiting for a lock or waiting for some external connection. In the second case, you are almost done. In the first case (waiting for a lock) we must find out, which lock and where. This means going up (to older) some stack frames looking for "code" objects. When a code object is dereferenced, it reveals the filename ("co_filename") it was defined in and the function name ("co_name") it is code for. Both are pointers to "PyStringObject"s and may need to be cast correspondingly. The string content is found starting at "ob_sval". Unfortunately, you cannot use the Python functions normally used to access and display Python objects as they will block. You must use elementary debugger commands. As you see, the debugging may not be easy but we might find a deeply hidden problem... Dieter