Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: "Caldarale, Charles R" <Chuck.Caldarale@unisys.com>
To: Tomcat Users List <users@tomcat.apache.org>
Date: Wed, 3 Mar 2010 11:45:34 -0600
Subject: RE: Tomcat threads
Thread-Topic: Tomcat threads
Thread-Index: Acq69gWoXZplSZO1S1qNTW/Yr/Hn5AAAC3WA
Message-ID: 
 <99C8B2929B39C24493377AC7A121E21F96CB8758AE@USEA-EXCH8.na.uis.unisys.com>
References: <6c81069d1003021547x297e5ee7r1ad66f67bf46dd@mail.gmail.com>
 	<99C8B2929B39C24493377AC7A121E21F96CB817BB2@USEA-EXCH8.na.uis.unisys.com>
 	<6c81069d1003021625n18601bffq52d9b920e28d4d20@mail.gmail.com>
 	<99C8B2929B39C24493377AC7A121E21F96CB817BE5@USEA-EXCH8.na.uis.unisys.com>
 	<6c81069d1003021642j3fd995d4s4d99c4cab86572df@mail.gmail.com>
 	<99C8B2929B39C24493377AC7A121E21F96CB817CA7@USEA-EXCH8.na.uis.unisys.com>
 <6c81069d1003030921l5c686987jb1bed5c2d2dbda3e@mail.gmail.com>
In-Reply-To: <6c81069d1003030921l5c686987jb1bed5c2d2dbda3e@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> From: Bharath Vasudevan [mailto:bharath.cng@gmail.com]
> Subject: Re: Tomcat threads
>=20
> When tomcat gets a request, it does a socket send to some=20
> other process to handle the request and then respond.

Tomcat doesn't do that - your webapp does.

You have now introduced a previously unmentioned dependency - that the resp=
onse depends on the behavior of an external resource, unrelated to Tomcat. =
 That changes the picture considerably.  The neat thing the servlet 3.0 Asy=
ncContext does is handle this case by letting you decouple the original Req=
uest and Response objects from the original processing thread.

> But assuming 20k client requests come in at the same time,
> the server would try to allocate 20k threads and handle it.

No, the server will allocate maxThreads request handlers; the other request=
s would sit in the TCP stack's queue (not in the JVM), up to the configured=
 acceptCount value - which you can set as high as your OS allows.

> Mostly the system would trash and go down.

Which is my point about why you don't want to set maxThreads to arbitrarily=
 large (or small) values.

> But if it was to be handled gracefully, we can have the=20
> threads pick up the request throw it in a queue and let
> the worker threads work and respond.

Which you can do in your webapp by sending an interim response to the clien=
t and having the client poll for the final one.  You'd have to disable keep=
-alives as well.  The 3.0 spec allows the container to perform this task, r=
ather than requiring the webapp to do so.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MA=
TERIAL 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 atta=
chments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org