On 3/1/06, Peter Lin <[EMAIL PROTECTED]> wrote: > On 2/28/06, Tomasz Nowak <[EMAIL PROTECTED]> wrote: > > > > > > > > I've not noticed more then 400-500 java threads, but I'll monitor > > that. I've set different ulimits form differnt users, BUT user > > that runs java/tomcat has no limits but one: -s 2048 (stacksize). > > > > AFAIK that one was recommended by RELEASE-NOTES.txt > > > > -- > > T. > > > > > > > that seems odd. in the original message the connector settings was this > > <Connector port="8009" protocol="AJP/1.3" > maxThreads="200" minSpareThreads="25" maxSpareThreads="50" > backlog="20" connectionTimeout="10000" > enableLookups="true" redirectPort="8443" /> > > if there's more than 400 threads, that would suggest the webapp is creating > threads and not handling them correctly. If the guess is correct, a simple > way to prove it is to deploy the app in Resin and use JMeter to generate 1-4 > million requests. Resin should also crash, if the webapp is creating threads > and letting them zombie.
Sorry, but that's not quite true. As far as we've tested, resin is able to survive an OutOfMemoryError upon thread creation. Tomcat brings an OOME and stops doing anything useful, resin just prints the error to the stderr.log, but remaining threads continue working, thus being more robust. Tested with 3.0.8 against 5.0.25 under linux 2.4.x in september 2004. Regards Leon > > ultimately, the webapp needs to be profiled to make sure it behaves > correctly. > > peter > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
