In fact, cap it at 10 and watch the app dring to a halt before it even gets going. This is a pretty compelling example. If the pool is drying up, they're definately screwing up.
It is. But developers may reply: "You are using less connections than those specified in (the contract) / (the manual) / (fill in yourself)".
I thinks we're misunderstanding each other. I think that when the pool is capped, and the connections are never returned, you get to a point where the pool refuses to give you a new connection, no matter how long you wait.
This is a pretty good idea for some basic debugging. You should only have to demonstrate to your devs that you can deadlock their server by capping the connection pool. After that, it's their problem, right? :)
With the proposal, you demonstrate they have a connection leak, which is the real problem.
Once you showed them they had ONE connection leak, you can urge them to dig for other connection leaks themselves.
But, of course, the idea about the deadlock seems really good also. If I understood, what you mean is: "If you set the connection pool size too low for the app, it should crash at will (or better, show an 'unavailable' screen), but it should continue working as soon as load permits it." Am I wrong?
I'm thinking that the connections are added to the pool upon request (from his observationa, it looks like the 10 pre-allocated connections are always ignored), and then never returned. The pool remembers the pre-allocated ones, plus the ones it created on-the-fly. I think that if he caps the connection pool size at 25, it will only take 20 requests to lock up the server for want of a DB connection.
Try setting the pool size to 11 and see if you lock up after one request ;)
-chris
signature.asc
Description: OpenPGP digital signature
