>It's the top frames that are critical, of course, since they show where the thread is stuck.
That stack trace is not from when the thread is hung - I put a bp on the entry point to my code so that I could see what code an incoming request must go thru before being passed to my code - my theory being that my commit requests were stuck somewhere in there. I don't believe my code is stuck in the top 4 frames, since when I recreate the problem, there are no threads that are sitting in that code - I see no evidence of the commit requests that have been sent from the client. >Because you're not releasing the connections back to the pool. Yes - my requests that are attempting to release the connections back to the pool are not arriving in my code. My client is sending them, but they are not arriving at my server. >If I have interpreted that statement correctly, you have a fatally flawed application architecture. Each Understood - we are in the process of re-writing some of this logic. However, poor design or not, I see no reason why Tomcat stops processing incoming requests when an underlying pool (that it should have no knowledge of) has been depleted. I am pursuing this point because it occurs to me that Tomcat is not behaving as I would expect - perhaps I misunderstand what Tomcat is doing, in which case I'm looking for guidance. Perhaps there is a subtle bug here, or misconfiguration on my part (other than the obvious undersizing of the pool - but that should just cause poor performance, rather than non-functional code). -- View this message in context: http://www.nabble.com/Tomcat-thread-pool-question-tp20915752p20937425.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
