You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Berglas, Anthony" <an...@rsa.com> on 2008/01/14 08:33:45 UTC
Effect of MaxThreads
Tomcat connectors provide maxThreads parameter to throttle the number of
concurrent transactions. But what actually happens when this number is
exceeded? Are additional requests queued, or are they simply bounced?
We have Apache in front of Tomcat (for dubious reasons). Where is the
best place to throttle, Apache or Tomcat?
Any ideas welcome.
Thanks,
Anthony
--
Dr Anthony Berglas
Ph. +61 7 3227 4410
Mob. +61 44 838 8874
ABerglas@RSA.com; Anthony@Berglas.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Effect of MaxThreads
Posted by Rainer Jung <ra...@kippdata.de>.
How do you connect httpd to Tomcat? Via mod_jk, mod_proxy_http or
mod_proxy_ajp?
Which MPM do you use in httpd, prefork (single-threaded) or worker
(multi-threaded) or something else?
To give you hints, it would be nice to see your connector configuration,
and the configuration of your httpd to Tomcat connection module (e.g.
mod_jk) and the MPM config as well.
What do you mean by "tried it" and by "it did fail"?
Regards,
Rainer
Berglas, Anthony wrote:
> Thanks for this. We tried it and it did fail. I don't understand the
> reasoning though, I would have thought that the whole point of a queue
> is to queue requests for which there is no available threads. And I
> would hope that threads would be returned to the pool when a request
> ends.
>
> It is not really Threads that we want to control, but rather the number
> of concurrent servlet requests processed.
>
> One other odd thing is that when we ran our multi threaded clients from
> two different client machines at the same time we received failures. It
> felt like different connectors were being used for different client
> machines, which does not make sense. They both reference the server
> with the same URL.
>
> We have Apache in front of Tomcat (for dubious but required reasons).
>
> Anyway, the bottom line is that I could not get maxThreads/acceptCount
> to effectively throttle calls to the servlets. (Which was required
> because the max connections parameter could not be set via JNDI for the
> Oracle Connection pooler, which was required because the application
> specifies the password which DBCP could not handle.)
>
> Regards,
>
> Anthony
>
>> -----Original Message-----
>> From: news [mailto:news@ger.gmane.org] On Behalf Of Bill Barker
>> Sent: Tuesday, January 15, 2008 12:09 PM
>> To: users@tomcat.apache.org
>> Subject: Re: Effect of MaxThreads
>>
>> Yes, but the way that the default, non-APR, AJP/1.3 Connector works,
>> connections generally will stay open tying up the corresponding
> threads.
>> This means that acceptCount doesn't really do very much in this case.
>> Tomcat will end up failing the request if it can't find a free thread
> for
>> it.
>>
>> The APR and (experimental) NIO AJP/1.3 Connectors don't have this
> problem,
>> since they don't have any link between the number of threads (which
> are
>> only
>> for active requests) and number of Socket connections.
>>
>> "Caldarale, Charles R" <Ch...@unisys.com> wrote in message
>> news:2828B04F0113CD468E6D1D51DF4362A4047CF377@USEA-
>> EXCH2.na.uis.unisys.com...
>>> From: Berglas, Anthony [mailto:anthony.berglas@rsa.com]
>>> Subject: Effect of MaxThreads
>>>
>>> Tomcat connectors provide maxThreads parameter to throttle
>>> the number of concurrent transactions. But what actually
>>> happens when this number is exceeded?
>> It's in the doc:
>> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
>>
>> "acceptCount - The maximum queue length for incoming connection
> requests
>> when all possible request processing threads are in use. Any requests
>> received when the queue is full will be refused. The default value is
>> 10."
>>
>>> We have Apache in front of Tomcat (for dubious reasons).
>> So why not remove the httpd overhead?
>>
>> - 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Effect of MaxThreads
Posted by "Berglas, Anthony" <an...@rsa.com>.
Thanks for this. We tried it and it did fail. I don't understand the
reasoning though, I would have thought that the whole point of a queue
is to queue requests for which there is no available threads. And I
would hope that threads would be returned to the pool when a request
ends.
It is not really Threads that we want to control, but rather the number
of concurrent servlet requests processed.
One other odd thing is that when we ran our multi threaded clients from
two different client machines at the same time we received failures. It
felt like different connectors were being used for different client
machines, which does not make sense. They both reference the server
with the same URL.
We have Apache in front of Tomcat (for dubious but required reasons).
Anyway, the bottom line is that I could not get maxThreads/acceptCount
to effectively throttle calls to the servlets. (Which was required
because the max connections parameter could not be set via JNDI for the
Oracle Connection pooler, which was required because the application
specifies the password which DBCP could not handle.)
Regards,
Anthony
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Bill Barker
> Sent: Tuesday, January 15, 2008 12:09 PM
> To: users@tomcat.apache.org
> Subject: Re: Effect of MaxThreads
>
> Yes, but the way that the default, non-APR, AJP/1.3 Connector works,
> connections generally will stay open tying up the corresponding
threads.
> This means that acceptCount doesn't really do very much in this case.
> Tomcat will end up failing the request if it can't find a free thread
for
> it.
>
> The APR and (experimental) NIO AJP/1.3 Connectors don't have this
problem,
> since they don't have any link between the number of threads (which
are
> only
> for active requests) and number of Socket connections.
>
> "Caldarale, Charles R" <Ch...@unisys.com> wrote in message
> news:2828B04F0113CD468E6D1D51DF4362A4047CF377@USEA-
> EXCH2.na.uis.unisys.com...
> > From: Berglas, Anthony [mailto:anthony.berglas@rsa.com]
> > Subject: Effect of MaxThreads
> >
> > Tomcat connectors provide maxThreads parameter to throttle
> > the number of concurrent transactions. But what actually
> > happens when this number is exceeded?
>
> It's in the doc:
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
>
> "acceptCount - The maximum queue length for incoming connection
requests
> when all possible request processing threads are in use. Any requests
> received when the queue is full will be refused. The default value is
> 10."
>
> > We have Apache in front of Tomcat (for dubious reasons).
>
> So why not remove the httpd overhead?
>
> - 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 start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Effect of MaxThreads
Posted by Bill Barker <wb...@wilshire.com>.
Yes, but the way that the default, non-APR, AJP/1.3 Connector works,
connections generally will stay open tying up the corresponding threads.
This means that acceptCount doesn't really do very much in this case.
Tomcat will end up failing the request if it can't find a free thread for
it.
The APR and (experimental) NIO AJP/1.3 Connectors don't have this problem,
since they don't have any link between the number of threads (which are only
for active requests) and number of Socket connections.
"Caldarale, Charles R" <Ch...@unisys.com> wrote in message
news:2828B04F0113CD468E6D1D51DF4362A4047CF377@USEA-EXCH2.na.uis.unisys.com...
> From: Berglas, Anthony [mailto:anthony.berglas@rsa.com]
> Subject: Effect of MaxThreads
>
> Tomcat connectors provide maxThreads parameter to throttle
> the number of concurrent transactions. But what actually
> happens when this number is exceeded?
It's in the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
"acceptCount - The maximum queue length for incoming connection requests
when all possible request processing threads are in use. Any requests
received when the queue is full will be refused. The default value is
10."
> We have Apache in front of Tomcat (for dubious reasons).
So why not remove the httpd overhead?
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Effect of MaxThreads
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Berglas, Anthony [mailto:anthony.berglas@rsa.com]
> Subject: Effect of MaxThreads
>
> Tomcat connectors provide maxThreads parameter to throttle
> the number of concurrent transactions. But what actually
> happens when this number is exceeded?
It's in the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
"acceptCount - The maximum queue length for incoming connection requests
when all possible request processing threads are in use. Any requests
received when the queue is full will be refused. The default value is
10."
> We have Apache in front of Tomcat (for dubious reasons).
So why not remove the httpd overhead?
- 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org