That (with a high probability) is because some objects they store in sessions are not Serializable. IOW, they violate the Servlet Specification.
I'm just curious: is this actually a violation of the servlet spec? The API seems to indicate that you can put anything in the session that you want. I don't think it has to be Serializable... thought I was wrong before, once ;)
I'm not 100% sure. What I am sure is that you cannot user session replication or session persistence without this.
Tried that. Capped it at 35 and the webserver stopped servicing any DB request as soon as the pool reached 35. This is why I believe the pool management is faulty and/or something is hogging all the connections.
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)".
It depends on the size of your rollback segments and the number of transactions you are doing. If you do big transactions, each DB connection (thread *or* process) wioll need a big chunk of memory. I wouldn't kill yourself trying to figure out how to reduce this process size. Fix the real problem, which is poor connection management.
No doubt...
I've seen code like this before. Many people think you can't get a stack trace unless you throw an exception. Not so. All you have to do is instantiate it, and you get the stack trace. So, the following will produce identical results, without the nasty try/throw/catch:
new Exception("Pool debugged says: ...").printStackTrace();
I thought I had tried that (JDK1.3) and I thought it had not worked. Glad to know it does...
I would recommend explicitly printing out the hashCode of the Connection object itself, just in case the connection doesn't include any identifying information in it's .toString method.
Oh. Of course... I never happened to come across such a braindead Connection class.
Then you can... #!/bin/sh # Filter pool debugger statements.
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?
Yours,
Antonio Fiol
smime.p7s
Description: S/MIME Cryptographic Signature
