Actually, closer inspection of the stack trace reveals something interesting: there is one thread where the __del__ method on the ConnectionFairy is getting called within the get() method of Queue, and creating a reentrant lockup since __del__ tries to return the connection to the Pool, calls put() on Queue, and the mutex is already grabbed by the enclosing get().
Changeset 1657 commits some initialization to change Queue's mutex to be a threading.RLock, and the two threading.Conditions to derive from it, so that a put() wtihin a get() wont hang within a single thread. I think this might be the actual thing going on, although i cannot reproduce a __del__ getting called just like that. i think 1657 might solve your problem. this also might be a cue to start thinking about not using Queue.Queue for the connection pool, since im never a fan of changing internals like that. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
