tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Vasudevan <>
Subject Re: Tomcat threads
Date Wed, 03 Mar 2010 00:42:55 GMT
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 <> wrote:

> > From: Bharath Vasudevan []
> > 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.
> "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
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message