[ZODB-Dev] Opening 7 Connections hangs (and __del__)

Christian Reis kiko@async.com.br
Fri, 31 Jan 2003 12:42:32 -0200


Hi there,

I've just found out an interesting "feature" with the ZODB. We're using
the ZEO to connect to a ServerStorage based on FileStorage, and our
clients issue a number of db.open() calls (since we now use Shane's
awesome setLocalTransaction change).

I've found out that calling db.open() more than 6 times causes the
client to hang - when I try to get a 7th simultaneous connection the
application hangs. Granted, that's a bit extreme, but it's still odd.
The server is unaffected. I've tested this both *with* and *without*
setLocalTransaction, and it hangs with both. This is all using
ClientStorage with ZODB3 CVS HEAD server and client.

If you keep the number of connections *under* 7, you're safe. This can
be done by explicitly calling conn.close(). It strikes me as a bit odd,
but Connection has no __del__() method, which to me implies that no
cleanup is done after it?

I've worked around this problem by wrapping Connection in our
application and then setting a __del__() method to call
connection.close() but I'm left wondering two things which I *think*
are bugs:

    a) Why does calling db.open() 7 times hang?
    b) Why doesn't the Connection class clean up after it's dead?

The top 7 lines in the stack trace (the rest are our app-specific
bits):

#0  0x400bc24a in sigsuspend () from /lib/libc.so.6
#1  0x400221ff in pthread_cond_wait (cond=0x8473424, mutex=0x8473430)
    at restart.h:49
#2  0x8086ffb in PyThread_acquire_lock (lock=0x8473420, waitflag=1)
    at Python/thread_pthread.h:324
#3  0x8088848 in lock_PyThread_acquire_lock (self=0x83915e8, args=0x0)
    at ./Modules/threadmodule.c:67
#4  0x8073468 in fast_cfunction (func=0x846aa28, pp_stack=0xbffff2b8, na=0)
    at Python/ceval.c:3007
#5  0x8071c9a in eval_code2 (co=0x82a9418, globals=0x82ac4d4, locals=0x0, 
    args=0x81d15e4, argcount=1, kws=0x81d15e8, kwcount=0, defs=0x829fbb0, 
    defcount=5, closure=0x0) at Python/ceval.c:1963
#6  0x807351f in fast_function (func=0x82bb654, pp_stack=0xbffff3b8, n=1, 
    na=1, nk=0) at Python/ceval.c:3035

`func' in this frame is db.open(). I assume this has to do with something
with lock starvation but since I'm not very sharp on threads, I can't
deduce much. Does anyone make more sense out of it?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL