| it looks totally like Queue.Queue. but i cant find any mention of people having a problem like this with Queue.Queue, except one that pointed to that redhat bug.
Looking at your stacktrace, it is almost certainly a problem with the threading library; every single thread is stuck on acquiring one of two mutexes within Queue, however, *there are no threads blocking within either of those critical sections!* there is basically no thread that actually *has* either lock, yet none can acquire it. its like the threading.Conditional just died.
On Jun 25, 2006, at 10:24 PM, Dennis Muhlestein wrote: Ok, The servers are running on Xen virtual machines (3.0.1). The OS for the host and the guest both are Gentoo. They both use nptl for threading. (glibc 2.3.6). I couldn't tell from the Redhat bug report if they were using similar glibc and nptl as I have. If this problem persists, I could possibly try a different guest OS.
I've been looking into database locks in my investigations as well as the python code. Postgresql has a setting that can automatically termintate deadlocks after a given amount of time. I turned that on to see if any statements were killed. I haven't had any lockups since that, but I haven't seen any error messages of statements being killed either so perhaps I got lucky this weekend. The stack traces certainly point at the mutex in the Queue and not at the database.
As far as pool configuration, I'm not doing anything. I passed in the postgresql connection string to create_engine and left it at that. I have 40 server threads and have tried values between that and 150. My database (different dedicated physical machine) allows up to 128 connections. I noticed that during a lockup, there were actually only 8 or 9 established connections to the database. When one server was locked up, the other server was operating fine which also seems to not point at a database query being deadlocked.
On 6/25/06, Michael Bayer <[EMAIL PROTECTED]> wrote: also what OS/server/etc. are you running on ? this is a strange problem youre having, im wondering if youre on a platform with threading problems, as I have found this (red hat 9 threading busted) :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86416 in other news, the "timeout" parameter in SQLAlchemy's pool is broken; but that shouldnt be causing the problem youre having. (I cant see any way to reproduce the problem youre having, its totally within Queue.Queue, which I shouldnt be able to deadlock like that) On Jun 23, 2006, at 1:35 PM, Dennis Muhlestein wrote:
Thank you for the input
On 6/23/06, Michael Bayer < [EMAIL PROTECTED]> wrote: assuming youre using postgres, when it hangs you should take a look at the pg_locks table:
and also you should install the threadframe module:
Here are the stack traces of my locked threads:
There server is still in this state (I have two operating now), so if anyone can provide insight into debugging things I can type to figure out what is happening, I'm available to chat on MSN or skype.
Thanks
Dennis
|
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
