Hi I want to get access to some Zope objects stored in ZODB, from *outside* of any other Zope object (so I dont have anything to call getPhysicalRoot() or restrictedTraverse() on) but from *inside* python code running in the Zope process. This doesnt work: from Zope import Zope app = Zope.app() app.restrictedTraverse(...) The Zope server freezes, I guess there is a deadlock there. Currently, I'm using a single instance of a bogus product (a singleton) stored at the root of the Zope hierarchy, just to get access to the ZODB. I dont like it being a product nor being stored in the Zope database, but I cant access the Zope DB otherwise. How could I do that? Gabriel Genellina Softlab SRL
Gabriel Genellina wrote at 2003-3-24 19:25 -0300:
I want to get access to some Zope objects stored in ZODB, from *outside* of any other Zope object (so I dont have anything to call getPhysicalRoot() or restrictedTraverse() on) but from *inside* python code running in the Zope process. This doesnt work:
from Zope import Zope app = Zope.app() app.restrictedTraverse(...)
The Zope server freezes, I guess there is a deadlock there.
Does this already happens for the first time? It would be understandable when it happes after some successes unless you close the ZODB connection when you are finished: Zope.app() opens a ZODB connection which must be closed later. There is a connection pool (of 7 connections, by default). The application blocks when there are no free connections. Dieter
At 25/3/2003 20:43, you wrote:
I want to get access to some Zope objects stored in ZODB, from *outside* of any other Zope object (so I dont have anything to call getPhysicalRoot() or restrictedTraverse() on) but from *inside* python code running in the Zope process. This doesnt work:
from Zope import Zope app = Zope.app() app.restrictedTraverse(...)
The Zope server freezes, I guess there is a deadlock there.
Does this already happens for the first time?
It would be understandable when it happes after some successes unless you close the ZODB connection when you are finished:
Zope.app() opens a ZODB connection which must be closed later. There is a connection pool (of 7 connections, by default). The application blocks when there are no free connections.
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). Gabriel Genellina Softlab SRL
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
participants (2)
-
Dieter Maurer -
Gabriel Genellina