On Friday, December 6, 2013 10:16:21 AM UTC-5, Sunil Adapa wrote: > > Before making a connection attempt the overflow counter lock is obtained > and it is being released only after the connection either succeeds or > fails. In my case, a connection remained hung possibly because of a surge > in new DB connections and SYN backlog overflew on the database server (I > have since added a timeout and tuned my database server to have much higher > backlog). While this connection didn't respond, any new connection attempt > as seen in the above trace waited trying to acquire overflow lock. The > whole application became in capable of serving requests. Cause is this code: >
It sounds to me like you have an anti-pattern somewhere. Your entire application shouldn't hang because of a database connectivity issue. Specific requests to code that is trying to interact with the database should hang -- but the application shouldn't itself. SqlAlchemy shouldn't even connect to the database on a request that doesn't have DB logic in it. The immediate concern I see with your fix -- at least in your situation -- is that it could create a further surge and backlog on the MySQL server. I've worked with a few large online properties where some sort of surge like this ( where a bunch of app-servers kept reconnecting to mysql in a short time ) ended up creating a self-inflicted Denial of Service that took the sites offline, and in most of the instances the DB got corrupted and had to be repaired. This could be a good fix, Mike is the arbiter of all that stuff -- but this seems to me like it would facilitate a different problem. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
