Thanks Chuck. One thing I am not able to get is why would the user care if the response was done from a different thread? Is it not going to be opaque to the user as long as its fast?
If we get a request on a thread, let some other thread do the work for it and store the response info. The thread which does the work writes the response on that request. Regards, Bharath On Tue, Mar 2, 2010 at 3:57 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Bharath Vasudevan [mailto:bharath....@gmail.com] > > Subject: Tomcat threads > > > > Are they user level threads or kernel threads? > > Depends on the particular JVM being used, not on Tomcat. Pretty much all > modern JVMs use a kernel thread for each java.lang.Thread instance on which > start() has been called. > > > I see that the requests are kicked off through the threads from a pool > > (which has a configured size), how can this be scalable? > > Because you can make the limit as large as you want. Making it too large > leaves you open to DOS attacks and running out of resources on the server. > > > Also, from my understanding in servlets, the response for a > > request in has to be done then and there (as in I cant respond > > for a request later in future from some random thread) . > > That's the nature of HTTP, not servlets in particular. A properly designed > application facing a long-duration situation will usually send an interim > status back to the client, and kick off an auxiliary thread to do whatever > is going to run for a while. The auxiliary thread places the final response > in some location associated with the client when it's ready. The client > polls for status and the final response using JavaScript or some other > mechanism. > > > If there is contention for a resource which might take time > > (causing the response to take time), wont tomcat run out of > > threads? > > Yes; Tomcat won't care, but your users might. Don't use poorly designed > applications. > > - 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: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
