-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Smith,

On 1/18/17 8:25 PM, smith wrote:
> I don't care if the threads will be reduced, I just want to know
> why.

Okay.

> And we want to use the account to determine when the tomcat
> capacity is not enough that we need to add max configuration or add
> new tomcat servers.

Set your initial and max threads to the same value (pool size =
constant) and then monitor the "active count" with a Nagios warning at
e.g. 80% usage.

> Since not use the <Executor>, the busy thread account also cannot 
> tell us the correct active threads count.

"busy" is the same as "active".

> In another email thread, you said if use <Executor>, it will tell
> us the right active thread count not just busy count, right?

I would always use an <Executor> for at least two different reasons:

1. Thread management (e.g. reducing threads if necessary)
2. Shared thread-pools (no need to have port 8080 and 8443 with
separate pools)

- -chris

> -----Original Message----- From: Christopher Schultz 
> [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 18, 
> 2017 3:28 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 
> thread not reduced
> 
> Smith,
> 
> On 1/18/17 12:47 AM, smith wrote:
>> So the tomcat default executor will not reduce the thread count 
>> until it reach to the max configuration?
> 
> By default, you get a thread pool that isn't as smart as an 
> executor.
> 
>> Will it reduce when it reach to max?
> 
> Not unless you use an <Executor>.
> 
>> And why the default not reduce the thread?
> 
> Because it didn't do so in the past, before <Executor> was 
> introduced.
> 
> I'm curious: if you are willing to have e.g. 200 threads available
> at any time during the life of the JVM, why does it matter if
> those threads are reduced during times of inactivity?
> 
> I think of threads as a resource like memory, where if you are
> going to allocate X resources, you may as well allocate X resources
> and be done with it. Growing and shrinking pools of things just
> adds complexity and reduces performance.
> 
> Idle threads are "free" other than using a little bit of memory.
> So why is it so important for those threads to stop when they don't
> have any work for a while?
> 
> -chris
> 
>> -----Original Message----- From: Christopher Schultz 
>> [mailto:ch...@christopherschultz.net] Sent: Tuesday, January 17,
>>  2017 7:18 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 
>> thread not reduced
> 
>> Smith,
> 
>> On 1/16/17 8:22 PM, smith wrote:
>>> Yes, I think thread count should be reduced when those threads 
>>> are idle
> 
>>> Is this right? Or it will not reduced?
> 
>> Id you want Tomcat to reduce the number of idle threads, you'll 
>> need to explicitly configure an <Executor> and use that with your
>>  <Connector> .
> 
>> -chris
> 
>>> -----Original Message----- From: Christopher Schultz 
>>> [mailto:ch...@christopherschultz.net] Sent: Monday, January 16,
>>>  2017 2:20 PM To: Tomcat Users List Subject: Re: FW: tomcat
>>> 8080 thread not reduced
> 
>>> Smith,
> 
>>> There are your only active <Connector>s:
> 
>>> On 1/14/17 1:30 AM, smith wrote:
>>>> <Connector port="8080" protocol="HTTP/1.1" maxThreads="300" 
>>>> connectionTimeout="20000" redirectPort="8443" />
> 
>>>> [snip]
> 
>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
>>>>  />
> 
>>> You have not changed any settings from the default. What makes 
>>> you think that your thread count should be reduced when those 
>>> threads are idle?
> 
>>> -chris
> 
>>> --------------------------------------------------------------------
- -
>
>>>
>>> 
>>> 
> 
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
>>> --------------------------------------------------------------------
- -
>
>>>
>>> 
>>> 
> 
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
>> ---------------------------------------------------------------------
>
>>
>> 
> 
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
>> ---------------------------------------------------------------------
>
>>
>> 
> 
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYgOtqAAoJEBzwKT+lPKRYzssP/RYY4eIAw8DS39+2z3uk7zva
OChcof7S6yclKCQ4KjpVq9lsSPndOjOt4MaWtMyktKEoKIjvn25f/KSDJLIUy7HX
T5t/8NAix/BbkNlBeQjGDN5rrx3QUWuudb4E1ERydafWDt1cBfb+ry2jdLxa7x7g
TbQkP+tFl4C59lJ3P+vkqr2qZiUT8VSR5ljXxK1i6EWrT7oN3D0xCai5fEV7rgUZ
ah3Xj5QXztu+Tw/8e0rkFn/8KnUv+zLVvc/wTgr+nd9hKuYXMk11nOQfnIsLS5vO
VmxJJBmLb0UFFWw50ST8248caJjRsOnMbUeJqcc+71PJ6aeZ2hoxZXVXyLJuNENH
LIlUTRjSwa7Ij02InUJ/xj8uQg0cm4ayBWDbfOz2ki23GtD5UgUKBDLTxDp2JqaZ
uUwzkHSTv4P9x+NDK4/oYDJ38if6/XF4kClm2LqLoGccb4pENdnP4QMQxUTNLnjg
OJwLEkbjinvfRe79ADoOlGIyKRMVg/qlSoPgSRnqqbHPXehBNlV7IQn+s3F/kK0A
gzMT30lZ0al3aANUy2852Bn+xmG9DhBkOTBio+bQiCBdMSE+J7BQ3YOjKLT7GcX5
Jg0i3LloP29PI5c5fmDn08Mr/kmJVf6KartGHp9W6QRfKeJVdVWzrHl3owKtl3y0
VCaH5idITnyUntc7akwi
=dWIg
-----END PGP SIGNATURE-----

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

Reply via email to