OK, this deadlock is entirely occuring as a result of the way the Queue.Queue module is being used, and its not related to a database-related deadlock as far as i can tell. which is a good thing ! because those things are hard to fix. now, the pool should be timing out when no more connections are present, but perhaps that is not working. so i will look into that. I have not yet built load testing frameworks for the pool module so it has not been fine tuned for heavy-load situations. however, one thing that should be done regardless of the pool's indefinite hanging problem, is that the total size of the thread pool being used by cherrypy should be smaller than the configured size of the connection pool. It seems possible that you have more threads looking for connections than there are connections available...can you tell me the configured size of your threading setup / configured size of your sqlalchemy pool ? information on basic options is available at : http://www.sqlalchemy.org/docs/dbengine.myt#dbengine_options On Jun 23, 2006, at 1:35 PM, Dennis Muhlestein wrote: Thank you for the input |
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