-----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