tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Vasudevan <bharath....@gmail.com>
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 <
Chuck.Caldarale@unisys.com> wrote:

> > From: Bharath Vasudevan [mailto:bharath.cng@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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