> From: André Warnier [mailto:[EMAIL PROTECTED] > Subject: Re: Tomcat thread pool question > > So it has nothing to do directly with the threads.
Only in determining how many requests can be accepted by Tomcat before going on the limited TCP/IP queue and subsequent requests being rejected. > I will suppose for now that the webapp saves each borrowed > connection, in some place related to the session-id of the > client that triggered the borrowing of each connection. I hope so; otherwise the application architecture is complete wishful thinking. > Think I got it. Yup. > But on the other hand, if you increase the number of threads above the > number of simultaneous clients that you could possibly have, then it > would unblock the situation, no ? In a test environment, that might be feasible; in the real world, it is highly unlikely that one has sufficient control over the clients to limit the number of requests that they might submit in toto. (It's not really the number of clients that's the problem; it's the number of concurrent requests, since there's nothing stopping a client from issuing multiple requests simultaneously. Given the poor design demonstrated so far by the app in question, I wouldn't be surprised that they aren't providing for that situation either.) > I'm not saying that it is a good design, but maybe it's a > temporary solution ? Maybe, but I would never condone putting such a scheme into production. I wonder what other shortcomings this app has... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
