Thanks again for the great response. I am not worried about the request processors any more now that i understand what they mean. However, i see that when i use the nio, my application gets stuck. i think working without nio is better. I am not sure why, if as i know nio is supposed to improve performance. I am checking my connectors configuration as well as my application getting stuck.
Christopher Schultz-2 wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michal, > > Michal Singer wrote: >> 1. request processors are equivalent to threads? > > Yes. The only thing that can execute code is a thread. Given your > configuration, it appears that you will have 500 maximum threads. > > I am a little unfamiliar with the NIO connector, but this is what the > documentation says when using useExecutor="true": > > " > If set to true(default) then the max pool size is the maxThreads > attribute and the core pool size is the minSpareThreads. This value is > ignored if the executor attribute is present and points to a valid > shared thread pool. > " > >> 2. doesn't nio work with one thread? (I thougt that this thread >> configuration is irrelevant since nio works with one thread to receive >> requests.) > > Nope. The NIO connector is just a non-blocking one. A single thread > could never supply suitable performance for a web application. You might > be thinking of Comet, which is a completely different beast. > > http://tomcat.apache.org/tomcat-6.0-doc/aio.html > >> 3. I shouldn't work with Executor while working with nio connector? > > Using the executor is perfectly find. I think Chuck and I were confused > since the executor is typically specified separately (as <Executor>) but > the documentation appears to suggest that an executor will be > automatically created given your configuration. > >> 4. can you send me an example of nio good configuration? > > Your configuration appears to be good, actually. The only problems are: > > 1. You are nervous about the number of request processors appearing > (and you probably shouldn't be, unless you are hardly using your > app at all and you are still seeing hundreds of request processor > threads being created) > > 2. Your application hangs, which is, of course, a serious problem. > > For that last one, you'll need to take thread dumps to find out what > your app is waiting on. You might want to scale back the number of > request processors (maxThreads setting) so your thread dumps are small > enough to read without losing your mind. > > My guess is that you are hitting your database thread pool limit and the > application is simply waiting for db connections to become available. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkkkMOQACgkQ9CaO5/Lv0PBYWACgwsqRM2XG4N1SOMSt722XlY/Q > MbkAnjjThQY/WEFv65JtmkdENyltkFCF > =yIAC > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Tomcat-request-processing-gets-stuck-tp20526036p20582385.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
