"scalable" also seems to be a relative term here, and there are well documented strategies for scalability. So, the question is, are you just looking for strategies for scalability or do you have a real problem with load?
-----Original Message----- From: Bharath Vasudevan [mailto:bharath....@gmail.com] Sent: Tuesday, March 02, 2010 6:43 PM To: Tomcat Users List Subject: Re: Tomcat threads Why is it illlogical? Fast is a relative term. If the number of requests increases, the number of threads that can be handled by the system goes down . The context switches and the pain to handle the switches makes handling of the requests in lesser threads which is scalable. On Tue, Mar 2, 2010 at 4:34 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Bharath Vasudevan [mailto:bharath....@gmail.com] > > Subject: Re: Tomcat threads > > > > 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. > > If the processing is fast, why would you go to the complexity and overhead > of switching to another thread to process the request? > > You should also read the servlet spec, in particular SRV.2.3.3.3: > > "Implementations of the request and response objects are not guaranteed to > be thread > safe. This means that they should only be used within the scope of the > request handling > thread. > > "References to the request and response objects should not be given to > objects > executing in other threads as the resulting behavior may be > nondeterministic. If > the thread created by the application uses the container-managed objects, > such as > the request or response object, those objects must be accessed only within > the > servlet's service life cycle and such thread itself should have a life > cycle within > the life cycle of the servlet's service method because accessing those > objects > after the service method ends may cause undeterministic problems." > > The illogical behavior you're asking for simply isn't allowed. > > - 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
