tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Morgan" <>
Subject RE: Tomcat threads
Date Wed, 03 Mar 2010 13:27:31 GMT
"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 [] 
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
. 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
> 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
> such as
> the request or response object, those objects must be accessed only
> 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
> 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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message