You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by smith <sm...@zoom.us> on 2017/01/13 08:38:28 UTC
FW: tomcat 8080 thread not reduced
From: smith [mailto:smith.hua@zoom.us]
Sent: Tuesday, January 10, 2017 9:57 AM
To: 'users'
Subject: tomcat 8080 thread not reduced
Hi,
We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
When will the thread reduce?
Best regards
Smith
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Hi, André
My case is same, my tomcat also has load balancer in front and it has health check to tomcat
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Wednesday, January 18, 2017 9:41 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
Hi.
I believe that what Philippe mentions below is somewhat different : in his configuration, there is apparently a front-end httpd server, which communicates with Tomcat via AJP and the tomcat AJP Connector.
In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates a series of connections to the back-end tomcat, and keeps these connections alive in a pool of connections, according to rules which are different, than what applies to your case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
So Philippe's case introduces probably an additional level of complexity into the equation.
semi-graphically :
smith case :
client <- HTTP -> tomcat HTTP connector - tomcat thread
Philippe's case :
client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
The real question is :
The tomcat 8.0 HTTP Connector documentation
(http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) mentions a series of attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing the number of threads dynamically (increasing the number of threads (up to maxThreads) when needed to process simultaneous requests, and decreasing the number of threads again (down to minSpareThreads) when less requests are being processed).
According to observations however (and to Chris' comments), that does not seem to be the case : once the number of threads has grown to a certain number, it never goes down back down again.
It has to be said that the above interpretation was mine, and the current documentation of the HTTP Connector never says explicitly that, on its own, it manages the number of threads dynamically. But it *does* mention a minSpareThreads parameter.
On the other hand, when you use an Executor (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation states explicitly that the number of threads *is* dynamically managed, up and down.
I found something else which seems to explain the riddle :
http://tomcat.apache.org/migration-6.html#Connector_thread_pools
That section explicitly says that since tomcat 6.0, for a Connector without an Executor, the number of threads always grows, and never decreases. And it also explicitly says that the Connector's "minSpareThreads" attribute will be ignored.
So in fact the only thing wrong, is the online documentation for the Connectors : the minSpareThreads attribute should be removed (since it is anyway ignored).
That seems to have been an oversight ever since tomcat 6.0.
As far as I am concerned thus, the mystery is solved.
One question which is a bit left open is :
What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle threads, as opposed to using an Executor to manage the number of threads dynamically ?
But that is probably the kind of question to which the appropriate answer is : "it depends.."
On 18.01.2017 07:33, smith wrote:
> Thanks, Philippe
>
> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>
> -----Original Message-----
> From: Philippe Busque [mailto:pbusque@mediagrif.com]
> Sent: Monday, January 16, 2017 8:09 PM
> To: users@tomcat.apache.org
> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>
> We're having a similar issues with our numberous Tomcat instances.
>
> Our connector config look like this.
>
> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="20000" URIEncoding="UTF-8" />
>
>
> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>
> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>
> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>
>
> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>
>
> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>
>
> Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
>> On 16.01.2017 11:10, smith wrote:
>>> We has same problem on dev env that no any traffic to the serive,
>>
>> Ah. That is /new/ information, which may change the suggestions below.
>> It looks like you should really find out what these threads are doing,
>> probably by doing a few thread dumps.
>> See here e.g. :
>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>
>> Again : we do not know your application, so we can only make guesses
>> based on the information that you provide.
>>
>> will try on dev first
>>>
>>> -----Original Message-----
>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Monday, January 16, 2017 10:08 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 16.01.2017 09:50, smith wrote:
>>>> Busy one is process customer request, do not know what non-busy one
>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>> will not cause so long connection
>>>>
>>>> -smith
>>>
>>> And did you actually try it ?
>>>
>>> We do not know your website or your application, so we cannot tell
>>> how many clients there are, what these clients are really requesting,
>>> how many requests each client is sending before going away, etc.
>>>
>>> KeepAlive means that when a client has sent its /last/ request and
>>> received the response, one thread is going to remain "not free" (but
>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>> client would still send another request (which it may never do,
>>> depending on the application).
>>>
>>> Imagine that your application is so that the average client
>>> - connects to your site
>>> - sends a single HTTP request, which gets processed in 0.1 s
>>> - receives the response
>>> - and then goes away
>>> and that the above sequence happens once every second, from different
>>> clients.
>>> After one second, there will be one thread waiting for another 19
>>> seconds before becoming free (and potentially destroyed or re-used).
>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>> but there will be 19 other threads still waiting, and one new thread
>>> just created.
>>> If everything stays perfectly regular like that, your will have
>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>> If you change the above so that there is a new client every 0.5 s,
>>> you will have permanently 40 threads (of which only 2 maximum are
>>> really doing something).
>>>
>>> The point is : KeepAlive is not "bad", and in some cases having a
>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>> having a high number of threads sitting idle is not necessarily a
>>> problem.
>>> Your own scenario is probably not like the above perfectly regular
>>> and irrealistic one above. But there may be a perfectly logical
>>> reason why you have so many threads on average, and I am just trying
>>> to give you ideas for finding out the reason.
>>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>
>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>> this parameter may has nothing to do with this
>>>>
>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>> and what are the non-busy ones doing ?
>>>>
>>>>
>>>>> --
>>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I can find nothing really wrong in your configuration below.
>>>>>> But, what happens if in this section :
>>>>>>
>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>> > redirectPort="8443" />
>>>>>>
>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>> the above 20 seconds) ?
>>>>>>
>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>
>>>>>> See :
>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>> Im
>>>>>> plementation
>>>>>> --> connectionTimeout
>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>
>>>>>>
>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>> The server.xml:
>>>>>>>
>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>> <!--
>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>> or more
>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>> distributed with
>>>>>>> this work for additional information regarding copyright
>>>>>>> ownership.
>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>> Version 2.0
>>>>>>> (the "License"); you may not use this file except in
>>>>>>> compliance with
>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>
>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>
>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>> software
>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>> BASIS,
>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>> express or implied.
>>>>>>> See the License for the specific language governing
>>>>>>> permissions and
>>>>>>> limitations under the License.
>>>>>>> -->
>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>> Documentation at /docs/config/server.html
>>>>>>> -->
>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>> <!-- Security listener. Documentation at
>>>>>>> /docs/config/listeners.html
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>> -->
>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>> SSLEngine="on" />
>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>> java/javax APIs-->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>> />
>>>>>>>
>>>>>>> <!-- Global JNDI resources
>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>> -->
>>>>>>> <GlobalNamingResources>
>>>>>>> <!-- Editable user database that can also be used by
>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>> -->
>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>> description="User database that can be updated
>>>>>>> and saved"
>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>> </GlobalNamingResources>
>>>>>>>
>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>> "Connectors" that share
>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>> a "Container",
>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>> at this level.
>>>>>>> Documentation at /docs/config/service.html
>>>>>>> -->
>>>>>>> <Service name="Catalina">
>>>>>>>
>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>> define one or more named thread pools-->
>>>>>>> <!--
>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>> namePrefix="catalina-exec-"
>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>> -->
>>>>>>>
>>>>>>>
>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>> requests are received
>>>>>>> and responses are returned. Documentation at :
>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>> (blocking & non-blocking)
>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>> -->
>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>> <!--
>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>> connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> -->
>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>> This connector uses the NIO implementation that
>>>>>>> requires the JSSE
>>>>>>> style configuration. When using the APR/native
>>>>>>> implementation, the
>>>>>>> OpenSSL style configuration is required as described
>>>>>>> in the APR/native
>>>>>>> documentation -->
>>>>>>> <!--
>>>>>>> <Connector port="8443"
>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>> scheme="https" secure="true"
>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>> redirectPort="8443" />
>>>>>>>
>>>>>>>
>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>> Catalina) that processes
>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>> stand alone
>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>> and passes them
>>>>>>> on to the appropriate Host (virtual host).
>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>
>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>> via AJP ie :
>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>> jvmRoute="jvm1">
>>>>>>> -->
>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>
>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>> at:
>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>> -->
>>>>>>> <!--
>>>>>>> <Cluster
>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>> user passwords
>>>>>>> via a brute-force attack -->
>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>> the global JNDI
>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>> that are performed against this UserDatabase are
>>>>>>> immediately
>>>>>>> available for use by the Realm. -->
>>>>>>> <Realm
>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>> resourceName="UserDatabase"/>
>>>>>>> </Realm>
>>>>>>>
>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>
>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>> web applications
>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>> <!--
>>>>>>> <Valve
>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Access log processes all example.
>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>> Note: The pattern used is equivalent to using
>>>>>>> pattern="common" -->
>>>>>>>
>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>> directory="logs"
>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>
>>>>>>> <Context path="" allowLinking="true"
>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>> </Host>
>>>>>>> </Engine>
>>>>>>> </Service>
>>>>>>> </Server>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>> To: 'users'
>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>
>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>
>>>>>>>> When will the thread reduce?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Smith
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>> look at it.
>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>> Often, the issue is in the details.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>
> Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
>
> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re[2]: FW: tomcat 8080 thread not reduced
Posted by Smith Hua <sm...@zoom.us>.
thanks, our monitor is getting the result from the tomcat manager page which provides the busy threads count and totol threads count
--
从myMail的Android专用app所发送 星期三, 18 一月 2017, 06:08下午 +08:00 发件人 André Warnier (tomcat) aw@ice-sa.com :
>On 18.01.2017 10:56, smith wrote:
>> Hi, André
>>
>> Thanks for the great explanation. So the current thread count will grow always until it reaches to the max configuration.
>>
>> I have another strange thing:
>> We never monitored tomcat busy thread count high (we monitored one minutes interval through Nagios to get tomcat manager result, not high than 10). So if the threads grows, it should monitored the busy thread count reach that high(or some lower). So I'm still not understand when the current thread count will grow while current busy thread has not change a lot.
>>
>
>I think that if you combine my explanation of the KeepAlive effect, with Philippe's notes,
>you may get the explanation.
>I would personally guess that your monitoring agent does not consider a thread that is
>idle in KeepAlive state, as "busy". So it only counts as busy, the threads which are
>effectively in the state of processing a request.
>(This is just a guess; I think you may want to draw a little time-dependent diagram, to
>see what really happens, with a KeepAlive of 20 seconds, and ping or heartbeat requests
>coming in regularly.)
>In any case, if you want to avoid this phenomenon altogether, try configuring an Executor.
>You need to configure the <Executor> itself, and then in your <Connector>, refer to that
>Executor).
>
>
>
>
>>
>>
>> -----Original Message-----
>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Wednesday, January 18, 2017 9:41 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> Hi.
>>
>> I believe that what Philippe mentions below is somewhat different : in his configuration, there is apparently a front-end httpd server, which communicates with Tomcat via AJP and the tomcat AJP Connector.
>> In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates a series of connections to the back-end tomcat, and keeps these connections alive in a pool of connections, according to rules which are different, than what applies to your case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
>> So Philippe's case introduces probably an additional level of complexity into the equation.
>> semi-graphically :
>>
>> smith case :
>>
>> client <- HTTP -> tomcat HTTP connector - tomcat thread
>>
>> Philippe's case :
>>
>> client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
>>
>> The real question is :
>>
>> The tomcat 8.0 HTTP Connector documentation
>> ( http://tomcat.apache.org/tomcat-8.0-doc/config/http.html ) mentions a series of attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
>> keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing the number of threads dynamically (increasing the number of threads (up to maxThreads) when needed to process simultaneous requests, and decreasing the number of threads again (down to minSpareThreads) when less requests are being processed).
>>
>> According to observations however (and to Chris' comments), that does not seem to be the case : once the number of threads has grown to a certain number, it never goes down back down again.
>> It has to be said that the above interpretation was mine, and the current documentation of the HTTP Connector never says explicitly that, on its own, it manages the number of threads dynamically. But it *does* mention a minSpareThreads parameter.
>>
>> On the other hand, when you use an Executor (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation states explicitly that the number of threads *is* dynamically managed, up and down.
>>
>> I found something else which seems to explain the riddle :
>>
>> http://tomcat.apache.org/migration-6.html#Connector_thread_pools
>> That section explicitly says that since tomcat 6.0, for a Connector without an Executor, the number of threads always grows, and never decreases. And it also explicitly says that the Connector's "minSpareThreads" attribute will be ignored.
>>
>> So in fact the only thing wrong, is the online documentation for the Connectors : the minSpareThreads attribute should be removed (since it is anyway ignored).
>> That seems to have been an oversight ever since tomcat 6.0.
>>
>> As far as I am concerned thus, the mystery is solved.
>>
>> One question which is a bit left open is :
>>
>> What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle threads, as opposed to using an Executor to manage the number of threads dynamically ?
>> But that is probably the kind of question to which the appropriate answer is : "it depends.."
>>
>>
>>
>>
>> On 18.01.2017 07:33, smith wrote:
>>> Thanks, Philippe
>>>
>>> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>>>
>>> -----Original Message-----
>>> From: Philippe Busque [mailto:pbusque@mediagrif.com]
>>> Sent: Monday, January 16, 2017 8:09 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>>>
>>> We're having a similar issues with our numberous Tomcat instances.
>>>
>>> Our connector config look like this.
>>>
>>> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
>>> enableLookups="false" redirectPort="8443" acceptCount="100"
>>> connectionTimeout="20000" URIEncoding="UTF-8" />
>>>
>>>
>>> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>>>
>>> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>>>
>>> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>>>
>>>
>>> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>>>
>>>
>>> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
>>> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>>>
>>>
>>> Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
>>>> On 16.01.2017 11:10, smith wrote:
>>>>> We has same problem on dev env that no any traffic to the serive,
>>>>
>>>> Ah. That is /new/ information, which may change the suggestions below.
>>>> It looks like you should really find out what these threads are doing,
>>>> probably by doing a few thread dumps.
>>>> See here e.g. :
>>>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>>>
>>>> Again : we do not know your application, so we can only make guesses
>>>> based on the information that you provide.
>>>>
>>>> will try on dev first
>>>>>
>>>>> -----Original Message-----
>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>> Sent: Monday, January 16, 2017 10:08 AM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>
>>>>> On 16.01.2017 09:50, smith wrote:
>>>>>> Busy one is process customer request, do not know what non-busy one
>>>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>>>> will not cause so long connection
>>>>>>
>>>>>> -smith
>>>>>
>>>>> And did you actually try it ?
>>>>>
>>>>> We do not know your website or your application, so we cannot tell
>>>>> how many clients there are, what these clients are really requesting,
>>>>> how many requests each client is sending before going away, etc.
>>>>>
>>>>> KeepAlive means that when a client has sent its /last/ request and
>>>>> received the response, one thread is going to remain "not free" (but
>>>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>>>> client would still send another request (which it may never do,
>>>>> depending on the application).
>>>>>
>>>>> Imagine that your application is so that the average client
>>>>> - connects to your site
>>>>> - sends a single HTTP request, which gets processed in 0.1 s
>>>>> - receives the response
>>>>> - and then goes away
>>>>> and that the above sequence happens once every second, from different
>>>>> clients.
>>>>> After one second, there will be one thread waiting for another 19
>>>>> seconds before becoming free (and potentially destroyed or re-used).
>>>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>>>> but there will be 19 other threads still waiting, and one new thread
>>>>> just created.
>>>>> If everything stays perfectly regular like that, your will have
>>>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>>>> If you change the above so that there is a new client every 0.5 s,
>>>>> you will have permanently 40 threads (of which only 2 maximum are
>>>>> really doing something).
>>>>>
>>>>> The point is : KeepAlive is not "bad", and in some cases having a
>>>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>>>> having a high number of threads sitting idle is not necessarily a
>>>>> problem.
>>>>> Your own scenario is probably not like the above perfectly regular
>>>>> and irrealistic one above. But there may be a perfectly logical
>>>>> reason why you have so many threads on average, and I am just trying
>>>>> to give you ideas for finding out the reason.
>>>>>
>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>>>> To: users@tomcat.apache.org
>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>
>>>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>>>
>>>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>>>> this parameter may has nothing to do with this
>>>>>>
>>>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>>>> and what are the non-busy ones doing ?
>>>>>>
>>>>>>
>>>>>>> --
>>>>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> I can find nothing really wrong in your configuration below.
>>>>>>>> But, what happens if in this section :
>>>>>>>>
>>>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>>>> > redirectPort="8443" />
>>>>>>>>
>>>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>>>> the above 20 seconds) ?
>>>>>>>>
>>>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>>>
>>>>>>>> See :
>>>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>>>> Im
>>>>>>>> plementation
>>>>>>>> --> connectionTimeout
>>>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>>>> The server.xml:
>>>>>>>>>
>>>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>>>> <!--
>>>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>>>> or more
>>>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>>>> distributed with
>>>>>>>>> this work for additional information regarding copyright
>>>>>>>>> ownership.
>>>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>>>> Version 2.0
>>>>>>>>> (the "License"); you may not use this file except in
>>>>>>>>> compliance with
>>>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>>>
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>>>
>>>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>>>> software
>>>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>>>> BASIS,
>>>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>>>> express or implied.
>>>>>>>>> See the License for the specific language governing
>>>>>>>>> permissions and
>>>>>>>>> limitations under the License.
>>>>>>>>> -->
>>>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>>>> Documentation at /docs/config/server.html
>>>>>>>>> -->
>>>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>>>> <!-- Security listener. Documentation at
>>>>>>>>> /docs/config/listeners.html
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>>>> -->
>>>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>>>> SSLEngine="on" />
>>>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>>>> java/javax APIs-->
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>>>> />
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>>>> />
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>>>> />
>>>>>>>>>
>>>>>>>>> <!-- Global JNDI resources
>>>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>>>> -->
>>>>>>>>> <GlobalNamingResources>
>>>>>>>>> <!-- Editable user database that can also be used by
>>>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>>>> -->
>>>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>>>> description="User database that can be updated
>>>>>>>>> and saved"
>>>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>>>> </GlobalNamingResources>
>>>>>>>>>
>>>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>>>> "Connectors" that share
>>>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>>>> a "Container",
>>>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>>>> at this level.
>>>>>>>>> Documentation at /docs/config/service.html
>>>>>>>>> -->
>>>>>>>>> <Service name="Catalina">
>>>>>>>>>
>>>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>>>> define one or more named thread pools-->
>>>>>>>>> <!--
>>>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>>>> namePrefix="catalina-exec-"
>>>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>>>> requests are received
>>>>>>>>> and responses are returned. Documentation at :
>>>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>>>> (blocking & non-blocking)
>>>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>>>> -->
>>>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>>>> <!--
>>>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>>>> connectionTimeout="20000"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>> -->
>>>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>>>> This connector uses the NIO implementation that
>>>>>>>>> requires the JSSE
>>>>>>>>> style configuration. When using the APR/native
>>>>>>>>> implementation, the
>>>>>>>>> OpenSSL style configuration is required as described
>>>>>>>>> in the APR/native
>>>>>>>>> documentation -->
>>>>>>>>> <!--
>>>>>>>>> <Connector port="8443"
>>>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>>>> scheme="https" secure="true"
>>>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>>>> Catalina) that processes
>>>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>>>> stand alone
>>>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>>>> and passes them
>>>>>>>>> on to the appropriate Host (virtual host).
>>>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>>>
>>>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>>>> via AJP ie :
>>>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>>>> jvmRoute="jvm1">
>>>>>>>>> -->
>>>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>>>
>>>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>>>> at:
>>>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>>>> -->
>>>>>>>>> <!--
>>>>>>>>> <Cluster
>>>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>>>> user passwords
>>>>>>>>> via a brute-force attack -->
>>>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>>>> the global JNDI
>>>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>>>> that are performed against this UserDatabase are
>>>>>>>>> immediately
>>>>>>>>> available for use by the Realm. -->
>>>>>>>>> <Realm
>>>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>>>> resourceName="UserDatabase"/>
>>>>>>>>> </Realm>
>>>>>>>>>
>>>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>>>
>>>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>>>> web applications
>>>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>>>> <!--
>>>>>>>>> <Valve
>>>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Access log processes all example.
>>>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>>>> Note: The pattern used is equivalent to using
>>>>>>>>> pattern="common" -->
>>>>>>>>>
>>>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>>>> directory="logs"
>>>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>>>
>>>>>>>>> <Context path="" allowLinking="true"
>>>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>>>> </Host>
>>>>>>>>> </Engine>
>>>>>>>>> </Service>
>>>>>>>>> </Server>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>>>
>>>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>>>> To: 'users'
>>>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>>>
>>>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>>>
>>>>>>>>>> When will the thread reduce?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>>
>>>>>>>>>> Smith
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>>>> look at it.
>>>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>>>> Often, the issue is in the details.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>
>>> Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
>>>
>>> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Smith,
On 1/18/17 7:42 AM, Smith Hua wrote:
> our monitor is getting the result from the tomcat manager page
> which provides the busy threads count and totol threads count, i'm
> not sure if tomcat manager treat the keepAlived thread as free.
If you are using AJP as your protocol, then keepalive is pretty much
irrelevant, since the threads used on the Tomcat side are essentially
permanently bound to a connection coming from the reverse proxy. Those
connections aren't allocated to individual clients from the Internet;
they are aggregated and sent-over (mostly) permanent connections from
the reverse proxy to Tomcat.
> if the tomcat manager treat the keepAlived thread as free, seems we
> can't kown what's the concurrent work threads, when we need to add
> the max threads or add more tomcat servers. shall we use current
> total threads to judge this? if it reaches to max configured
> threads, need to add max threads or add tomcat servers?
The data point you actually want to look at is called "activeCount" on
the thread pool. If you aren't using an <Executor>, then you should be
using one.
See
http://people.apache.org/~schultz/ApacheCon%20NA%202016/Monitoring%20Apa
che%20Tomcat%20with%20JMX.pdf
starting on slide 17.
- -chris
> -- \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e09, 18 \u4e00\u6708 2017, 06:08\u4e0b\u5348 +08:00 \u53d1\u4ef6\u4eba
> Andr� Warnier (tomcat) aw@ice-sa.com :
>
>> On 18.01.2017 10:56, smith wrote:
>>> Hi, Andr�
>>>
>>> Thanks for the great explanation. So the current thread count
>>> will grow always until it reaches to the max configuration.
>>>
>>> I have another strange thing: We never monitored tomcat busy
>>> thread count high (we monitored one minutes interval through
>>> Nagios to get tomcat manager result, not high than 10). So if
>>> the threads grows, it should monitored the busy thread count
>>> reach that high(or some lower). So I'm still not understand
>>> when the current thread count will grow while current busy
>>> thread has not change a lot.
>>>
>>
>> I think that if you combine my explanation of the KeepAlive
>> effect, with Philippe's notes, you may get the explanation. I
>> would personally guess that your monitoring agent does not
>> consider a thread that is idle in KeepAlive state, as "busy". So
>> it only counts as busy, the threads which are effectively in the
>> state of processing a request. (This is just a guess; I think you
>> may want to draw a little time-dependent diagram, to see what
>> really happens, with a KeepAlive of 20 seconds, and ping or
>> heartbeat requests coming in regularly.) In any case, if you want
>> to avoid this phenomenon altogether, try configuring an Executor.
>> You need to configure the <Executor> itself, and then in your
>> <Connector>, refer to that Executor).
>>
>>
>>
>>
>>>
>>>
>>> -----Original Message----- From: Andr� Warnier (tomcat)
>>> [mailto:aw@ice-sa.com] Sent: Wednesday, January 18, 2017 9:41
>>> AM To: users@tomcat.apache.org Subject: Re: FW: tomcat 8080
>>> thread not reduced
>>>
>>> Hi.
>>>
>>> I believe that what Philippe mentions below is somewhat
>>> different : in his configuration, there is apparently a
>>> front-end httpd server, which communicates with Tomcat via AJP
>>> and the tomcat AJP Connector. In such a case, the "mod_jk" or
>>> "mod_proxy_ajp" connector module inside of httpd, creates a
>>> series of connections to the back-end tomcat, and keeps these
>>> connections alive in a pool of connections, according to rules
>>> which are different, than what applies to your case (which
>>> consists of direct HTTP connections from browsers, to the
>>> tomcat HTTP connector). So Philippe's case introduces probably
>>> an additional level of complexity into the equation.
>>> semi-graphically :
>>>
>>> smith case :
>>>
>>> client <- HTTP -> tomcat HTTP connector - tomcat thread
>>>
>>> Philippe's case :
>>>
>>> client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat
>>> AJP connector - tomcat thread
>>>
>>> The real question is :
>>>
>>> The tomcat 8.0 HTTP Connector documentation (
>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html )
>>> mentions a series of attributes/parameters (maxThreads,
>>> minSpareThreads, connectionTimeout, keepAliveTimeout,..)
>>> which, together, would lead one to believe that tomcat is
>>> managing the number of threads dynamically (increasing the
>>> number of threads (up to maxThreads) when needed to process
>>> simultaneous requests, and decreasing the number of threads
>>> again (down to minSpareThreads) when less requests are being
>>> processed).
>>>
>>> According to observations however (and to Chris' comments),
>>> that does not seem to be the case : once the number of threads
>>> has grown to a certain number, it never goes down back down
>>> again. It has to be said that the above interpretation was
>>> mine, and the current documentation of the HTTP Connector never
>>> says explicitly that, on its own, it manages the number of
>>> threads dynamically. But it *does* mention a minSpareThreads
>>> parameter.
>>>
>>> On the other hand, when you use an Executor
>>> (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html),
>>>
>>>
then the documentation states explicitly that the number of
>>> threads *is* dynamically managed, up and down.
>>>
>>> I found something else which seems to explain the riddle :
>>>
>>> http://tomcat.apache.org/migration-6.html#Connector_thread_pools
>>> That section explicitly says that since tomcat 6.0, for a
>>> Connector without an Executor, the number of threads always
>>> grows, and never decreases. And it also explicitly says that
>>> the Connector's "minSpareThreads" attribute will be ignored.
>>>
>>> So in fact the only thing wrong, is the online documentation
>>> for the Connectors : the minSpareThreads attribute should be
>>> removed (since it is anyway ignored). That seems to have been
>>> an oversight ever since tomcat 6.0.
>>>
>>> As far as I am concerned thus, the mystery is solved.
>>>
>>> One question which is a bit left open is :
>>>
>>> What - if any - is the real advantage/disadvantage of having
>>> perhaps maxThreads idle threads, as opposed to using an
>>> Executor to manage the number of threads dynamically ? But that
>>> is probably the kind of question to which the appropriate
>>> answer is : "it depends.."
>>>
>>>
>>>
>>>
>>> On 18.01.2017 07:33, smith wrote:
>>>> Thanks, Philippe
>>>>
>>>> But we never monitored tomcat busy thread count high (we
>>>> monitored one minutes interval through nagios to get tomcat
>>>> manager result, not high than 10). This is strange
>>>>
>>>> -----Original Message----- From: Philippe Busque
>>>> [mailto:pbusque@mediagrif.com] Sent: Monday, January 16,
>>>> 2017 8:09 PM To: users@tomcat.apache.org Subject: Re: Re:
>>>> FW: tomcat 8080 thread not reduced
>>>>
>>>> We're having a similar issues with our numberous Tomcat
>>>> instances.
>>>>
>>>> Our connector config look like this.
>>>>
>>>> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
>>>> enableLookups="false" redirectPort="8443" acceptCount="100"
>>>> connectionTimeout="20000" URIEncoding="UTF-8" />
>>>>
>>>>
>>>> Sometime, the number of active connection would jump very
>>>> high (up to 190), due to some external issues (database lock,
>>>> etc) and threads would accumulate.
>>>>
>>>> Even though a connectionTimeout is set, and therefor set
>>>> keepAliveTimeout as the same value, threads are never
>>>> released once the problem is resolved until Tomcat is
>>>> restarted. We would end up with maybe 5-10 busy workers, but
>>>> 190 idle workers/ threads
>>>>
>>>> I think the issue is related to how the
>>>> StandardThreadExecutor is implemented. The
>>>> StandardThreadExecutor is a front for the default Java
>>>> ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor
>>>> is distributing work in round robin fashion among all defined
>>>> workers, rather than sticking to the core threads.
>>>>
>>>>
>>>> As a result, should a website has any constant traffic
>>>> (Apache AJP ping, load balancer monitoring, normal traffic,
>>>> etc), all thread will be hit at least once within the
>>>> configured keepAliveTimeout, reseting it. So unless the
>>>> keepAliveTimeout is set to a very low value, which defeat the
>>>> purpose, thread will never be released .
>>>>
>>>>
>>>> This is what I've come to suspect from looking at the
>>>> StandardThreadExecutor, but never really had the opportunity
>>>> to do deeper test with load. But from Tomcat 6 to tomcat 8,
>>>> we were never able to decrease the number of 'idle' workers
>>>> back from the highest value it had reached.
>>>>
>>>>
>>>> Le 2017-01-16 � 05:24, Andr� Warnier (tomcat) a �crit :
>>>>> On 16.01.2017 11:10, smith wrote:
>>>>>> We has same problem on dev env that no any traffic to
>>>>>> the serive,
>>>>>
>>>>> Ah. That is /new/ information, which may change the
>>>>> suggestions below. It looks like you should really find
>>>>> out what these threads are doing, probably by doing a few
>>>>> thread dumps. See here e.g. :
>>>>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>>>>
>>>>>
>>>>>
>>>>>
Again : we do not know your application, so we can only make guesses
>>>>> based on the information that you provide.
>>>>>
>>>>> will try on dev first
>>>>>>
>>>>>> -----Original Message----- From: Andr� Warnier (tomcat)
>>>>>> [mailto:aw@ice-sa.com] Sent: Monday, January 16, 2017
>>>>>> 10:08 AM To: users@tomcat.apache.org Subject: Re: FW:
>>>>>> tomcat 8080 thread not reduced
>>>>>>
>>>>>> On 16.01.2017 09:50, smith wrote:
>>>>>>> Busy one is process customer request, do not know what
>>>>>>> non-busy one is doing, always keep 120 for many days.
>>>>>>> I don't think 20s timeout will not cause so long
>>>>>>> connection
>>>>>>>
>>>>>>> -smith
>>>>>>
>>>>>> And did you actually try it ?
>>>>>>
>>>>>> We do not know your website or your application, so we
>>>>>> cannot tell how many clients there are, what these
>>>>>> clients are really requesting, how many requests each
>>>>>> client is sending before going away, etc.
>>>>>>
>>>>>> KeepAlive means that when a client has sent its /last/
>>>>>> request and received the response, one thread is going
>>>>>> to remain "not free" (but doing nothing) for the duration
>>>>>> of the KeepAlive timeout. This thread will keep waiting,
>>>>>> for KeepAliveTimeout seconds, just in case the client
>>>>>> would still send another request (which it may never do,
>>>>>> depending on the application).
>>>>>>
>>>>>> Imagine that your application is so that the average
>>>>>> client - connects to your site - sends a single HTTP
>>>>>> request, which gets processed in 0.1 s - receives the
>>>>>> response - and then goes away and that the above
>>>>>> sequence happens once every second, from different
>>>>>> clients. After one second, there will be one thread
>>>>>> waiting for another 19 seconds before becoming free (and
>>>>>> potentially destroyed or re-used). After 2 seconds, there
>>>>>> will be 2 such threads. After 3 seconds, 3 threads. And
>>>>>> so on. After 20 seconds, the first thread will be freed,
>>>>>> but there will be 19 other threads still waiting, and one
>>>>>> new thread just created. If everything stays perfectly
>>>>>> regular like that, your will have /permanently/ 20
>>>>>> threads in existence, even if the minimum is 10. If you
>>>>>> change the above so that there is a new client every 0.5
>>>>>> s, you will have permanently 40 threads (of which only 2
>>>>>> maximum are really doing something).
>>>>>>
>>>>>> The point is : KeepAlive is not "bad", and in some cases
>>>>>> having a relatively long KeepAliveTimeout is the right
>>>>>> thing to do. Also, having a high number of threads
>>>>>> sitting idle is not necessarily a problem. Your own
>>>>>> scenario is probably not like the above perfectly regular
>>>>>> and irrealistic one above. But there may be a perfectly
>>>>>> logical reason why you have so many threads on average,
>>>>>> and I am just trying to give you ideas for finding out
>>>>>> the reason.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: Andr� Warnier
>>>>>>> (tomcat) [mailto:aw@ice-sa.com] Sent: Monday, January
>>>>>>> 16, 2017 8:33 AM To: users@tomcat.apache.org Subject:
>>>>>>> Re: FW: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>>>>
>>>>>>>> actually there is not much busy threads, less tahn
>>>>>>>> 10,so i think this parameter may has nothing to do
>>>>>>>> with this
>>>>>>>
>>>>>>> It depends on what you call "busy". What are the busy
>>>>>>> ones doing ? and what are the non-busy ones doing ?
>>>>>>>
>>>>>>>
>>>>>>>> -- \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348
>>>>>>>> +08:00 \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> I can find nothing really wrong in your
>>>>>>>>> configuration below. But, what happens if in this
>>>>>>>>> section :
>>>>>>>>>
>>>>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>>>>> redirectPort="8443" />
>>>>>>>>>
>>>>>>>>> you change the connectionTimeout to 3000 (= 3
>>>>>>>>> seconds, instead of the above 20 seconds) ?
>>>>>>>>>
>>>>>>>>> Do you still see the number of threads remaining
>>>>>>>>> at the maximum ?
>>>>>>>>>
>>>>>>>>> See :
>>>>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Stand
ard_
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Im
>>>>>>>>> plementation --> connectionTimeout and the fact
>>>>>>>>> that it is also the default for keepAliveTimeout
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>>>>> The server.xml:
>>>>>>>>>>
>>>>>>>>>> <?xml version='1.0' encoding='utf-8'?> <!--
>>>>>>>>>> Licensed to the Apache Software Foundation (ASF)
>>>>>>>>>> under one or more contributor license
>>>>>>>>>> agreements. See the NOTICE file distributed with
>>>>>>>>>> this work for additional information regarding
>>>>>>>>>> copyright ownership. The ASF licenses this file
>>>>>>>>>> to You under the Apache License, Version 2.0 (the
>>>>>>>>>> "License"); you may not use this file except in
>>>>>>>>>> compliance with the License. You may obtain a
>>>>>>>>>> copy of the License at
>>>>>>>>>>
>>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>>>>
>>>>>>>>>> Unless required by applicable law or agreed to
>>>>>>>>>> in writing, software distributed under the
>>>>>>>>>> License is distributed on an "AS IS" BASIS,
>>>>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
>>>>>>>>>> either express or implied. See the License for
>>>>>>>>>> the specific language governing permissions and
>>>>>>>>>> limitations under the License. --> <!-- Note: A
>>>>>>>>>> "Server" is not itself a "Container", so you may
>>>>>>>>>> not define subcomponents such as "Valves" at this
>>>>>>>>>> level. Documentation at /docs/config/server.html
>>>>>>>>>> --> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>>>>> <Listener
>>>>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener"
>>>>>>>>>>
>>>>>>>>>>
/> <!-- Security listener. Documentation at
>>>>>>>>>> /docs/config/listeners.html <Listener
>>>>>>>>>> className="org.apache.catalina.security.SecurityListener"
>>>>>>>>>>
>>>>>>>>>>
/> --> <!--APR library loader. Documentation at
>>>>>>>>>> /docs/apr.html --> <Listener
>>>>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
SSLEngine="on" />
>>>>>>>>>> <!-- Prevent memory leaks due to use of
>>>>>>>>>> particular java/javax APIs--> <Listener
>>>>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionLi
stener"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
/>
>>>>>>>>>> <Listener
>>>>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycl
eListener"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
/>
>>>>>>>>>> <Listener
>>>>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPrevention
Listener"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
/>
>>>>>>>>>>
>>>>>>>>>> <!-- Global JNDI resources Documentation at
>>>>>>>>>> /docs/jndi-resources-howto.html -->
>>>>>>>>>> <GlobalNamingResources> <!-- Editable user
>>>>>>>>>> database that can also be used by
>>>>>>>>>> UserDatabaseRealm to authenticate users -->
>>>>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>>>>> description="User database that can be updated
>>>>>>>>>> and saved"
>>>>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
pathname="conf/tomcat-users.xml" />
>>>>>>>>>> </GlobalNamingResources>
>>>>>>>>>>
>>>>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>>>>> "Connectors" that share a single "Container"
>>>>>>>>>> Note: A "Service" is not itself a "Container", so
>>>>>>>>>> you may not define subcomponents such as "Valves"
>>>>>>>>>> at this level. Documentation at
>>>>>>>>>> /docs/config/service.html --> <Service
>>>>>>>>>> name="Catalina">
>>>>>>>>>>
>>>>>>>>>> <!--The connectors can use a shared executor,
>>>>>>>>>> you can define one or more named thread pools-->
>>>>>>>>>> <!-- <Executor name="tomcatThreadPool"
>>>>>>>>>> namePrefix="catalina-exec-" maxThreads="150"
>>>>>>>>>> minSpareThreads="4"/> -->
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <!-- A "Connector" represents an endpoint by
>>>>>>>>>> which requests are received and responses are
>>>>>>>>>> returned. Documentation at : Java HTTP
>>>>>>>>>> Connector: /docs/config/http.html (blocking &
>>>>>>>>>> non-blocking) Java AJP Connector:
>>>>>>>>>> /docs/config/ajp.html APR (HTTP/AJP) Connector:
>>>>>>>>>> /docs/apr.html Define a non-SSL HTTP/1.1
>>>>>>>>>> Connector on port 8080 --> <Connector port="8080"
>>>>>>>>>> protocol="HTTP/1.1" maxThreads="300"
>>>>>>>>>> connectionTimeout="20000" redirectPort="8443" />
>>>>>>>>>> <!-- A "Connector" using the shared thread
>>>>>>>>>> pool--> <!-- <Connector
>>>>>>>>>> executor="tomcatThreadPool" port="8080"
>>>>>>>>>> protocol="HTTP/1.1" connectionTimeout="20000"
>>>>>>>>>> redirectPort="8443" /> --> <!-- Define a SSL
>>>>>>>>>> HTTP/1.1 Connector on port 8443 This connector
>>>>>>>>>> uses the NIO implementation that requires the
>>>>>>>>>> JSSE style configuration. When using the
>>>>>>>>>> APR/native implementation, the OpenSSL style
>>>>>>>>>> configuration is required as described in the
>>>>>>>>>> APR/native documentation --> <!-- <Connector
>>>>>>>>>> port="8443"
>>>>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
maxThreads="150" SSLEnabled="true"
>>>>>>>>>> scheme="https" secure="true" clientAuth="false"
>>>>>>>>>> sslProtocol="TLS" /> -->
>>>>>>>>>>
>>>>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>>>>> redirectPort="8443" />
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>>>>> Catalina) that processes every request. The
>>>>>>>>>> Engine implementation for Tomcat stand alone
>>>>>>>>>> analyzes the HTTP headers included with the
>>>>>>>>>> request, and passes them on to the appropriate
>>>>>>>>>> Host (virtual host). Documentation at
>>>>>>>>>> /docs/config/engine.html -->
>>>>>>>>>>
>>>>>>>>>> <!-- You should set jvmRoute to support
>>>>>>>>>> load-balancing via AJP ie : <Engine
>>>>>>>>>> name="Catalina" defaultHost="localhost"
>>>>>>>>>> jvmRoute="jvm1"> --> <Engine name="Catalina"
>>>>>>>>>> defaultHost="localhost">
>>>>>>>>>>
>>>>>>>>>> <!--For clustering, please take a look at
>>>>>>>>>> documentation at: /docs/cluster-howto.html
>>>>>>>>>> (simple how to) /docs/config/cluster.html
>>>>>>>>>> (reference documentation) --> <!-- <Cluster
>>>>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
- -->
>>>>>>>>>>
>>>>>>>>>> <!-- Use the LockOutRealm to prevent attempts to
>>>>>>>>>> guess user passwords via a brute-force attack -->
>>>>>>>>>> <Realm
>>>>>>>>>> className="org.apache.catalina.realm.LockOutRealm">
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
<!-- This Realm uses the UserDatabase configured in
>>>>>>>>>> the global JNDI resources under the key
>>>>>>>>>> "UserDatabase". Any edits that are performed
>>>>>>>>>> against this UserDatabase are immediately
>>>>>>>>>> available for use by the Realm. --> <Realm
>>>>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
resourceName="UserDatabase"/>
>>>>>>>>>> </Realm>
>>>>>>>>>>
>>>>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>>>>
>>>>>>>>>> <!-- SingleSignOn valve, share authentication
>>>>>>>>>> between web applications Documentation at:
>>>>>>>>>> /docs/config/valve.html --> <!-- <Valve
>>>>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn"
>>>>>>>>>>
>>>>>>>>>>
/> -->
>>>>>>>>>>
>>>>>>>>>> <!-- Access log processes all example.
>>>>>>>>>> Documentation at: /docs/config/valve.html Note:
>>>>>>>>>> The pattern used is equivalent to using
>>>>>>>>>> pattern="common" -->
>>>>>>>>>>
>>>>>>>>>> <Valve
>>>>>>>>>> className="org.apache.catalina.valves.AccessLogValve"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
directory="logs"
>>>>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i"
>>>>>>>>>> />
>>>>>>>>>>
>>>>>>>>>> <Context path="" allowLinking="true"
>>>>>>>>>> crossContext="true" docBase="/****/t"
>>>>>>>>>> sessionCookieName="****" /> </Host> </Engine>
>>>>>>>>>> </Service> </Server>
>>>>>>>>>>
>>>>>>>>>> -----Original Message----- From: Andr� Warnier
>>>>>>>>>> (tomcat) [mailto:aw@ice-sa.com] Sent: Friday,
>>>>>>>>>> January 13, 2017 10:42 AM To:
>>>>>>>>>> users@tomcat.apache.org Subject: Re: FW: tomcat
>>>>>>>>>> 8080 thread not reduced
>>>>>>>>>>
>>>>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> From: smith [mailto:smith.hua@zoom.us] Sent:
>>>>>>>>>>> Tuesday, January 10, 2017 9:57 AM To: 'users'
>>>>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We have installed Apache Tomcat/8.0.14, and
>>>>>>>>>>> found that after one period of time, the thread
>>>>>>>>>>> count for 8080(our port published) goes to 120
>>>>>>>>>>> and never reduced even the busy count is only
>>>>>>>>>>> 3-4.
>>>>>>>>>>>
>>>>>>>>>>> Why? Tomcat8 not reduced the thread pool even
>>>>>>>>>>> the thread is idle, and the minSpareThreads
>>>>>>>>>>> for tomcat8 default is only 10.
>>>>>>>>>>>
>>>>>>>>>>> When will the thread reduce?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards
>>>>>>>>>>>
>>>>>>>>>>> Smith
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi.
>>>>>>>>>>
>>>>>>>>>> Please copy/paste your complete server.xml
>>>>>>>>>> configuration file (confidential things
>>>>>>>>>> removed), so that we could have a useful look at
>>>>>>>>>> it. Please edit *only* the confidential things,
>>>>>>>>>> not entire sections. Often, the issue is in the
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
- ----
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
- ----
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@tomcat.apache.org For
>>>>>>>>>> additional commands, e-mail:
>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
- ----
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
- ----
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail:
>>>>>>>>>> users-unsubscribe@tomcat.apache.org For
>>>>>>>>>> additional commands, e-mail:
>>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
- ----
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
- --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail:
>>>>>>>>> users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
- ----
>>>>>>>
>>>>>>>
>>>>>>>
- - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>> users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------
- ----
>>>>>>>
>>>>>>>
>>>>>>>
- - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail:
>>>>>>> users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
- ----
>>>>>>
>>>>>>
>>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
- ----
>>>>>>
>>>>>>
>>>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail:
>>>>>> users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>>>> Ce message et les fichiers d\u2019accompagnement transmis avec
>>>> celui-ci s\u2019adressent express�ment au(x) destinataire(s) et
>>>> peuvent contenir des renseignements confidentiels et
>>>> privil�gi�s. Si vous recevez ce message par erreur, veuillez
>>>> en aviser imm�diatement l\u2019exp�diteur par courrier
>>>> �lectronique. Veuillez �galement ne pas en prendre
>>>> connaissance et en supprimer toutes les copies imm�diatement.
>>>> Technologies Interactives Mediagrif Inc. et ses filiales
>>>> n\u2019acceptent aucune responsabilit� � l\u2019�gard des opinions
>>>> exprim�es dans le message ou des cons�quences de tout virus
>>>> informatique qui pourrait �tre transmis avec ce message. Ce
>>>> message fait �galement l\u2019objet d\u2019un copyright. Il est
>>>> interdit d\u2019en reproduire, adapter ou transmettre quelque
>>>> partie que ce soit sans le consentement �crit du d�tenteur du
>>>> copyright.
>>>>
>>>> This email and any files transmitted with it are solely
>>>> intended for the use of the addressee(s) and may contain
>>>> information that is confidential and privileged. If you
>>>> receive this email in error, please advise us by return
>>>> email immediately. Please also disregard the contents of the
>>>> email, delete it and destroy any copies immediately.
>>>> Mediagrif Interactive Technologies Inc. and its subsidiaries
>>>> do not accept liability for the views expressed in the email
>>>> or for the consequences of any computer viruses that may be
>>>> transmitted with this email. This email is also subject to
>>>> copyright. No part of it should be reproduced, adapted or
>>>> transmitted without the written consent of the copyright
>>>> owner.
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
>>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
- -
>>>
>>>
>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> --------------------------------------------------------------------
- -
>>>
>>>
>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYf4dvAAoJEBzwKT+lPKRYpSsP/2nL3k5sDoivMQPlYCm7Tz6J
TrUtLdOnFuHBMyDpDg5A3BaE7cUiXCFaBbMUV321NCWR6+62NEJ5yzaXzyrqr/Pw
2w4IfLI67N7Y2/x8eIn0yhN6m9//lf7pyD5tgWGg7jUFPEaYu1NgfVzrjcYZWT3l
Z3ZbvDSW8VVtJo3dQk4Ji4G93Q4rkMFBZDxEJpP9MdAfLAPI2X2Y+VkIdIbJVLLo
J2CAFx81RVctg7WA+4TNQodZmHEqAsT2JwBpYd/P/Du62rO0yvOXMVkzmgJG0RuE
Jh6gBmkwU2LiqdlDxvVvUQ7hor1Yz2Mz/4+jHxEhRMTUuUkzx/vhqRKiXUoEHPBO
Oh7495uhwCpssjMMe9iOVugQz5FgkV5e4ve1GMBxrW2JcWvHWXiveREgH0tOcFEf
IuFXUvzcHh6DSd39AlZbPuEiTLnRhmX2knl62nN5Ygza062QhA9lOPy4waR0b+pc
wqUzPSV7LBQWGga+oR0ti5EvIzFai3AAbSYBdzxGEyK2XP3SDsFAvSuIVC7bdbBF
lOR7++evP2PQKn+iWKbwihkBbl6OQ9Ny4/BOhYMAwjeZ6ga7ifBcvf/MuPYznjSC
rkUt7AUMoxeHqTWBnSycurNnDuu4R3zwo/BQAbmQGoBj3klbDNRFmV0bGQp2RcWt
sW80vS3hRaSo5OuOCizE
=zlwy
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re[2]: FW: tomcat 8080 thread not reduced
Posted by Smith Hua <sm...@zoom.us>.
thanks,
our monitor is getting the result from the tomcat manager page which provides the busy threads count and totol threads count, i'm not sure if tomcat manager treat the keepAlived thread as free.
if the tomcat manager treat the keepAlived thread as free, seems we can't kown what's the concurrent work threads, when we need to add the max threads or add more tomcat servers.
shall we use current total threads to judge this? if it reaches to max configured threads, need to add max threads or add tomcat servers?
--
从myMail的Android专用app所发送 星期三, 18 一月 2017, 06:08下午 +08:00 发件人 André Warnier (tomcat) aw@ice-sa.com :
>On 18.01.2017 10:56, smith wrote:
>> Hi, André
>>
>> Thanks for the great explanation. So the current thread count will grow always until it reaches to the max configuration.
>>
>> I have another strange thing:
>> We never monitored tomcat busy thread count high (we monitored one minutes interval through Nagios to get tomcat manager result, not high than 10). So if the threads grows, it should monitored the busy thread count reach that high(or some lower). So I'm still not understand when the current thread count will grow while current busy thread has not change a lot.
>>
>
>I think that if you combine my explanation of the KeepAlive effect, with Philippe's notes,
>you may get the explanation.
>I would personally guess that your monitoring agent does not consider a thread that is
>idle in KeepAlive state, as "busy". So it only counts as busy, the threads which are
>effectively in the state of processing a request.
>(This is just a guess; I think you may want to draw a little time-dependent diagram, to
>see what really happens, with a KeepAlive of 20 seconds, and ping or heartbeat requests
>coming in regularly.)
>In any case, if you want to avoid this phenomenon altogether, try configuring an Executor.
>You need to configure the <Executor> itself, and then in your <Connector>, refer to that
>Executor).
>
>
>
>
>>
>>
>> -----Original Message-----
>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Wednesday, January 18, 2017 9:41 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> Hi.
>>
>> I believe that what Philippe mentions below is somewhat different : in his configuration, there is apparently a front-end httpd server, which communicates with Tomcat via AJP and the tomcat AJP Connector.
>> In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates a series of connections to the back-end tomcat, and keeps these connections alive in a pool of connections, according to rules which are different, than what applies to your case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
>> So Philippe's case introduces probably an additional level of complexity into the equation.
>> semi-graphically :
>>
>> smith case :
>>
>> client <- HTTP -> tomcat HTTP connector - tomcat thread
>>
>> Philippe's case :
>>
>> client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
>>
>> The real question is :
>>
>> The tomcat 8.0 HTTP Connector documentation
>> ( http://tomcat.apache.org/tomcat-8.0-doc/config/http.html ) mentions a series of attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
>> keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing the number of threads dynamically (increasing the number of threads (up to maxThreads) when needed to process simultaneous requests, and decreasing the number of threads again (down to minSpareThreads) when less requests are being processed).
>>
>> According to observations however (and to Chris' comments), that does not seem to be the case : once the number of threads has grown to a certain number, it never goes down back down again.
>> It has to be said that the above interpretation was mine, and the current documentation of the HTTP Connector never says explicitly that, on its own, it manages the number of threads dynamically. But it *does* mention a minSpareThreads parameter.
>>
>> On the other hand, when you use an Executor (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation states explicitly that the number of threads *is* dynamically managed, up and down.
>>
>> I found something else which seems to explain the riddle :
>>
>> http://tomcat.apache.org/migration-6.html#Connector_thread_pools
>> That section explicitly says that since tomcat 6.0, for a Connector without an Executor, the number of threads always grows, and never decreases. And it also explicitly says that the Connector's "minSpareThreads" attribute will be ignored.
>>
>> So in fact the only thing wrong, is the online documentation for the Connectors : the minSpareThreads attribute should be removed (since it is anyway ignored).
>> That seems to have been an oversight ever since tomcat 6.0.
>>
>> As far as I am concerned thus, the mystery is solved.
>>
>> One question which is a bit left open is :
>>
>> What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle threads, as opposed to using an Executor to manage the number of threads dynamically ?
>> But that is probably the kind of question to which the appropriate answer is : "it depends.."
>>
>>
>>
>>
>> On 18.01.2017 07:33, smith wrote:
>>> Thanks, Philippe
>>>
>>> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>>>
>>> -----Original Message-----
>>> From: Philippe Busque [mailto:pbusque@mediagrif.com]
>>> Sent: Monday, January 16, 2017 8:09 PM
>>> To: users@tomcat.apache.org
>>> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>>>
>>> We're having a similar issues with our numberous Tomcat instances.
>>>
>>> Our connector config look like this.
>>>
>>> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
>>> enableLookups="false" redirectPort="8443" acceptCount="100"
>>> connectionTimeout="20000" URIEncoding="UTF-8" />
>>>
>>>
>>> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>>>
>>> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>>>
>>> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>>>
>>>
>>> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>>>
>>>
>>> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
>>> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>>>
>>>
>>> Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
>>>> On 16.01.2017 11:10, smith wrote:
>>>>> We has same problem on dev env that no any traffic to the serive,
>>>>
>>>> Ah. That is /new/ information, which may change the suggestions below.
>>>> It looks like you should really find out what these threads are doing,
>>>> probably by doing a few thread dumps.
>>>> See here e.g. :
>>>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>>>
>>>> Again : we do not know your application, so we can only make guesses
>>>> based on the information that you provide.
>>>>
>>>> will try on dev first
>>>>>
>>>>> -----Original Message-----
>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>> Sent: Monday, January 16, 2017 10:08 AM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>
>>>>> On 16.01.2017 09:50, smith wrote:
>>>>>> Busy one is process customer request, do not know what non-busy one
>>>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>>>> will not cause so long connection
>>>>>>
>>>>>> -smith
>>>>>
>>>>> And did you actually try it ?
>>>>>
>>>>> We do not know your website or your application, so we cannot tell
>>>>> how many clients there are, what these clients are really requesting,
>>>>> how many requests each client is sending before going away, etc.
>>>>>
>>>>> KeepAlive means that when a client has sent its /last/ request and
>>>>> received the response, one thread is going to remain "not free" (but
>>>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>>>> client would still send another request (which it may never do,
>>>>> depending on the application).
>>>>>
>>>>> Imagine that your application is so that the average client
>>>>> - connects to your site
>>>>> - sends a single HTTP request, which gets processed in 0.1 s
>>>>> - receives the response
>>>>> - and then goes away
>>>>> and that the above sequence happens once every second, from different
>>>>> clients.
>>>>> After one second, there will be one thread waiting for another 19
>>>>> seconds before becoming free (and potentially destroyed or re-used).
>>>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>>>> but there will be 19 other threads still waiting, and one new thread
>>>>> just created.
>>>>> If everything stays perfectly regular like that, your will have
>>>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>>>> If you change the above so that there is a new client every 0.5 s,
>>>>> you will have permanently 40 threads (of which only 2 maximum are
>>>>> really doing something).
>>>>>
>>>>> The point is : KeepAlive is not "bad", and in some cases having a
>>>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>>>> having a high number of threads sitting idle is not necessarily a
>>>>> problem.
>>>>> Your own scenario is probably not like the above perfectly regular
>>>>> and irrealistic one above. But there may be a perfectly logical
>>>>> reason why you have so many threads on average, and I am just trying
>>>>> to give you ideas for finding out the reason.
>>>>>
>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>>>> To: users@tomcat.apache.org
>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>
>>>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>>>
>>>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>>>> this parameter may has nothing to do with this
>>>>>>
>>>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>>>> and what are the non-busy ones doing ?
>>>>>>
>>>>>>
>>>>>>> --
>>>>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> I can find nothing really wrong in your configuration below.
>>>>>>>> But, what happens if in this section :
>>>>>>>>
>>>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>>>> > redirectPort="8443" />
>>>>>>>>
>>>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>>>> the above 20 seconds) ?
>>>>>>>>
>>>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>>>
>>>>>>>> See :
>>>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>>>> Im
>>>>>>>> plementation
>>>>>>>> --> connectionTimeout
>>>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>>>> The server.xml:
>>>>>>>>>
>>>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>>>> <!--
>>>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>>>> or more
>>>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>>>> distributed with
>>>>>>>>> this work for additional information regarding copyright
>>>>>>>>> ownership.
>>>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>>>> Version 2.0
>>>>>>>>> (the "License"); you may not use this file except in
>>>>>>>>> compliance with
>>>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>>>
>>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>>>
>>>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>>>> software
>>>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>>>> BASIS,
>>>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>>>> express or implied.
>>>>>>>>> See the License for the specific language governing
>>>>>>>>> permissions and
>>>>>>>>> limitations under the License.
>>>>>>>>> -->
>>>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>>>> Documentation at /docs/config/server.html
>>>>>>>>> -->
>>>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>>>> <!-- Security listener. Documentation at
>>>>>>>>> /docs/config/listeners.html
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>>>> -->
>>>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>>>> SSLEngine="on" />
>>>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>>>> java/javax APIs-->
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>>>> />
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>>>> />
>>>>>>>>> <Listener
>>>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>>>> />
>>>>>>>>>
>>>>>>>>> <!-- Global JNDI resources
>>>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>>>> -->
>>>>>>>>> <GlobalNamingResources>
>>>>>>>>> <!-- Editable user database that can also be used by
>>>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>>>> -->
>>>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>>>> description="User database that can be updated
>>>>>>>>> and saved"
>>>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>>>> </GlobalNamingResources>
>>>>>>>>>
>>>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>>>> "Connectors" that share
>>>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>>>> a "Container",
>>>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>>>> at this level.
>>>>>>>>> Documentation at /docs/config/service.html
>>>>>>>>> -->
>>>>>>>>> <Service name="Catalina">
>>>>>>>>>
>>>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>>>> define one or more named thread pools-->
>>>>>>>>> <!--
>>>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>>>> namePrefix="catalina-exec-"
>>>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>>>> requests are received
>>>>>>>>> and responses are returned. Documentation at :
>>>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>>>> (blocking & non-blocking)
>>>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>>>> -->
>>>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>>>> <!--
>>>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>>>> connectionTimeout="20000"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>> -->
>>>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>>>> This connector uses the NIO implementation that
>>>>>>>>> requires the JSSE
>>>>>>>>> style configuration. When using the APR/native
>>>>>>>>> implementation, the
>>>>>>>>> OpenSSL style configuration is required as described
>>>>>>>>> in the APR/native
>>>>>>>>> documentation -->
>>>>>>>>> <!--
>>>>>>>>> <Connector port="8443"
>>>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>>>> scheme="https" secure="true"
>>>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>>>> redirectPort="8443" />
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>>>> Catalina) that processes
>>>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>>>> stand alone
>>>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>>>> and passes them
>>>>>>>>> on to the appropriate Host (virtual host).
>>>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>>>
>>>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>>>> via AJP ie :
>>>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>>>> jvmRoute="jvm1">
>>>>>>>>> -->
>>>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>>>
>>>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>>>> at:
>>>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>>>> -->
>>>>>>>>> <!--
>>>>>>>>> <Cluster
>>>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>>>> user passwords
>>>>>>>>> via a brute-force attack -->
>>>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>>>> the global JNDI
>>>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>>>> that are performed against this UserDatabase are
>>>>>>>>> immediately
>>>>>>>>> available for use by the Realm. -->
>>>>>>>>> <Realm
>>>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>>>> resourceName="UserDatabase"/>
>>>>>>>>> </Realm>
>>>>>>>>>
>>>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>>>
>>>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>>>> web applications
>>>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>>>> <!--
>>>>>>>>> <Valve
>>>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>> <!-- Access log processes all example.
>>>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>>>> Note: The pattern used is equivalent to using
>>>>>>>>> pattern="common" -->
>>>>>>>>>
>>>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>>>> directory="logs"
>>>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>>>
>>>>>>>>> <Context path="" allowLinking="true"
>>>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>>>> </Host>
>>>>>>>>> </Engine>
>>>>>>>>> </Service>
>>>>>>>>> </Server>
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>>>
>>>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>>>> To: 'users'
>>>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>>>
>>>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>>>
>>>>>>>>>> When will the thread reduce?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards
>>>>>>>>>>
>>>>>>>>>> Smith
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>>>> look at it.
>>>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>>>> Often, the issue is in the details.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>
>>> Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
>>>
>>> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 18.01.2017 10:56, smith wrote:
> Hi, Andr�
>
> Thanks for the great explanation. So the current thread count will grow always until it reaches to the max configuration.
>
> I have another strange thing:
> We never monitored tomcat busy thread count high (we monitored one minutes interval through Nagios to get tomcat manager result, not high than 10). So if the threads grows, it should monitored the busy thread count reach that high(or some lower). So I'm still not understand when the current thread count will grow while current busy thread has not change a lot.
>
I think that if you combine my explanation of the KeepAlive effect, with Philippe's notes,
you may get the explanation.
I would personally guess that your monitoring agent does not consider a thread that is
idle in KeepAlive state, as "busy". So it only counts as busy, the threads which are
effectively in the state of processing a request.
(This is just a guess; I think you may want to draw a little time-dependent diagram, to
see what really happens, with a KeepAlive of 20 seconds, and ping or heartbeat requests
coming in regularly.)
In any case, if you want to avoid this phenomenon altogether, try configuring an Executor.
You need to configure the <Executor> itself, and then in your <Connector>, refer to that
Executor).
>
>
> -----Original Message-----
> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Wednesday, January 18, 2017 9:41 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> Hi.
>
> I believe that what Philippe mentions below is somewhat different : in his configuration, there is apparently a front-end httpd server, which communicates with Tomcat via AJP and the tomcat AJP Connector.
> In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates a series of connections to the back-end tomcat, and keeps these connections alive in a pool of connections, according to rules which are different, than what applies to your case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
> So Philippe's case introduces probably an additional level of complexity into the equation.
> semi-graphically :
>
> smith case :
>
> client <- HTTP -> tomcat HTTP connector - tomcat thread
>
> Philippe's case :
>
> client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
>
> The real question is :
>
> The tomcat 8.0 HTTP Connector documentation
> (http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) mentions a series of attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
> keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing the number of threads dynamically (increasing the number of threads (up to maxThreads) when needed to process simultaneous requests, and decreasing the number of threads again (down to minSpareThreads) when less requests are being processed).
>
> According to observations however (and to Chris' comments), that does not seem to be the case : once the number of threads has grown to a certain number, it never goes down back down again.
> It has to be said that the above interpretation was mine, and the current documentation of the HTTP Connector never says explicitly that, on its own, it manages the number of threads dynamically. But it *does* mention a minSpareThreads parameter.
>
> On the other hand, when you use an Executor (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation states explicitly that the number of threads *is* dynamically managed, up and down.
>
> I found something else which seems to explain the riddle :
>
> http://tomcat.apache.org/migration-6.html#Connector_thread_pools
> That section explicitly says that since tomcat 6.0, for a Connector without an Executor, the number of threads always grows, and never decreases. And it also explicitly says that the Connector's "minSpareThreads" attribute will be ignored.
>
> So in fact the only thing wrong, is the online documentation for the Connectors : the minSpareThreads attribute should be removed (since it is anyway ignored).
> That seems to have been an oversight ever since tomcat 6.0.
>
> As far as I am concerned thus, the mystery is solved.
>
> One question which is a bit left open is :
>
> What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle threads, as opposed to using an Executor to manage the number of threads dynamically ?
> But that is probably the kind of question to which the appropriate answer is : "it depends.."
>
>
>
>
> On 18.01.2017 07:33, smith wrote:
>> Thanks, Philippe
>>
>> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>>
>> -----Original Message-----
>> From: Philippe Busque [mailto:pbusque@mediagrif.com]
>> Sent: Monday, January 16, 2017 8:09 PM
>> To: users@tomcat.apache.org
>> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>>
>> We're having a similar issues with our numberous Tomcat instances.
>>
>> Our connector config look like this.
>>
>> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
>> enableLookups="false" redirectPort="8443" acceptCount="100"
>> connectionTimeout="20000" URIEncoding="UTF-8" />
>>
>>
>> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>>
>> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>>
>> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>>
>>
>> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>>
>>
>> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
>> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>>
>>
>> Le 2017-01-16 � 05:24, Andr� Warnier (tomcat) a �crit :
>>> On 16.01.2017 11:10, smith wrote:
>>>> We has same problem on dev env that no any traffic to the serive,
>>>
>>> Ah. That is /new/ information, which may change the suggestions below.
>>> It looks like you should really find out what these threads are doing,
>>> probably by doing a few thread dumps.
>>> See here e.g. :
>>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>>
>>> Again : we do not know your application, so we can only make guesses
>>> based on the information that you provide.
>>>
>>> will try on dev first
>>>>
>>>> -----Original Message-----
>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Monday, January 16, 2017 10:08 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 16.01.2017 09:50, smith wrote:
>>>>> Busy one is process customer request, do not know what non-busy one
>>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>>> will not cause so long connection
>>>>>
>>>>> -smith
>>>>
>>>> And did you actually try it ?
>>>>
>>>> We do not know your website or your application, so we cannot tell
>>>> how many clients there are, what these clients are really requesting,
>>>> how many requests each client is sending before going away, etc.
>>>>
>>>> KeepAlive means that when a client has sent its /last/ request and
>>>> received the response, one thread is going to remain "not free" (but
>>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>>> client would still send another request (which it may never do,
>>>> depending on the application).
>>>>
>>>> Imagine that your application is so that the average client
>>>> - connects to your site
>>>> - sends a single HTTP request, which gets processed in 0.1 s
>>>> - receives the response
>>>> - and then goes away
>>>> and that the above sequence happens once every second, from different
>>>> clients.
>>>> After one second, there will be one thread waiting for another 19
>>>> seconds before becoming free (and potentially destroyed or re-used).
>>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>>> but there will be 19 other threads still waiting, and one new thread
>>>> just created.
>>>> If everything stays perfectly regular like that, your will have
>>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>>> If you change the above so that there is a new client every 0.5 s,
>>>> you will have permanently 40 threads (of which only 2 maximum are
>>>> really doing something).
>>>>
>>>> The point is : KeepAlive is not "bad", and in some cases having a
>>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>>> having a high number of threads sitting idle is not necessarily a
>>>> problem.
>>>> Your own scenario is probably not like the above perfectly regular
>>>> and irrealistic one above. But there may be a perfectly logical
>>>> reason why you have so many threads on average, and I am just trying
>>>> to give you ideas for finding out the reason.
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>
>>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>>
>>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>>> this parameter may has nothing to do with this
>>>>>
>>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>>> and what are the non-busy ones doing ?
>>>>>
>>>>>
>>>>>> --
>>>>>> \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348 +08:00
>>>>>> \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> I can find nothing really wrong in your configuration below.
>>>>>>> But, what happens if in this section :
>>>>>>>
>>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>>> > redirectPort="8443" />
>>>>>>>
>>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>>> the above 20 seconds) ?
>>>>>>>
>>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>>
>>>>>>> See :
>>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>>> Im
>>>>>>> plementation
>>>>>>> --> connectionTimeout
>>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>>
>>>>>>>
>>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>>> The server.xml:
>>>>>>>>
>>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>>> <!--
>>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>>> or more
>>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>>> distributed with
>>>>>>>> this work for additional information regarding copyright
>>>>>>>> ownership.
>>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>>> Version 2.0
>>>>>>>> (the "License"); you may not use this file except in
>>>>>>>> compliance with
>>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>>
>>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>>
>>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>>> software
>>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>>> BASIS,
>>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>>> express or implied.
>>>>>>>> See the License for the specific language governing
>>>>>>>> permissions and
>>>>>>>> limitations under the License.
>>>>>>>> -->
>>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>>> Documentation at /docs/config/server.html
>>>>>>>> -->
>>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>>> <!-- Security listener. Documentation at
>>>>>>>> /docs/config/listeners.html
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>>> -->
>>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>>> SSLEngine="on" />
>>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>>> java/javax APIs-->
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>>> />
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>>> />
>>>>>>>> <Listener
>>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>>> />
>>>>>>>>
>>>>>>>> <!-- Global JNDI resources
>>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>>> -->
>>>>>>>> <GlobalNamingResources>
>>>>>>>> <!-- Editable user database that can also be used by
>>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>>> -->
>>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>>> description="User database that can be updated
>>>>>>>> and saved"
>>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>>> </GlobalNamingResources>
>>>>>>>>
>>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>>> "Connectors" that share
>>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>>> a "Container",
>>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>>> at this level.
>>>>>>>> Documentation at /docs/config/service.html
>>>>>>>> -->
>>>>>>>> <Service name="Catalina">
>>>>>>>>
>>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>>> define one or more named thread pools-->
>>>>>>>> <!--
>>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>>> namePrefix="catalina-exec-"
>>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>>> -->
>>>>>>>>
>>>>>>>>
>>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>>> requests are received
>>>>>>>> and responses are returned. Documentation at :
>>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>>> (blocking & non-blocking)
>>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>>> -->
>>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>>> redirectPort="8443" />
>>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>>> <!--
>>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>>> connectionTimeout="20000"
>>>>>>>> redirectPort="8443" />
>>>>>>>> -->
>>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>>> This connector uses the NIO implementation that
>>>>>>>> requires the JSSE
>>>>>>>> style configuration. When using the APR/native
>>>>>>>> implementation, the
>>>>>>>> OpenSSL style configuration is required as described
>>>>>>>> in the APR/native
>>>>>>>> documentation -->
>>>>>>>> <!--
>>>>>>>> <Connector port="8443"
>>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>>> scheme="https" secure="true"
>>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>>> -->
>>>>>>>>
>>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>>> redirectPort="8443" />
>>>>>>>>
>>>>>>>>
>>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>>> Catalina) that processes
>>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>>> stand alone
>>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>>> and passes them
>>>>>>>> on to the appropriate Host (virtual host).
>>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>>
>>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>>> via AJP ie :
>>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>>> jvmRoute="jvm1">
>>>>>>>> -->
>>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>>
>>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>>> at:
>>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>>> -->
>>>>>>>> <!--
>>>>>>>> <Cluster
>>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>>> -->
>>>>>>>>
>>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>>> user passwords
>>>>>>>> via a brute-force attack -->
>>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>>> the global JNDI
>>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>>> that are performed against this UserDatabase are
>>>>>>>> immediately
>>>>>>>> available for use by the Realm. -->
>>>>>>>> <Realm
>>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>>> resourceName="UserDatabase"/>
>>>>>>>> </Realm>
>>>>>>>>
>>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>>
>>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>>> web applications
>>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>>> <!--
>>>>>>>> <Valve
>>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>>> -->
>>>>>>>>
>>>>>>>> <!-- Access log processes all example.
>>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>>> Note: The pattern used is equivalent to using
>>>>>>>> pattern="common" -->
>>>>>>>>
>>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>>> directory="logs"
>>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>>
>>>>>>>> <Context path="" allowLinking="true"
>>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>>> </Host>
>>>>>>>> </Engine>
>>>>>>>> </Service>
>>>>>>>> </Server>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>>
>>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>>> To: 'users'
>>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>>
>>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>>
>>>>>>>>> When will the thread reduce?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Smith
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>>> look at it.
>>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>>> Often, the issue is in the details.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> ----
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----------------------------------------------------------------
>>>>>>>> ----
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>
>> Ce message et les fichiers d\u2019accompagnement transmis avec celui-ci s\u2019adressent express�ment au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privil�gi�s. Si vous recevez ce message par erreur, veuillez en aviser imm�diatement l\u2019exp�diteur par courrier �lectronique. Veuillez �galement ne pas en prendre connaissance et en supprimer toutes les copies imm�diatement. Technologies Interactives Mediagrif Inc. et ses filiales n\u2019acceptent aucune responsabilit� � l\u2019�gard des opinions exprim�es dans le message ou des cons�quences de tout virus informatique qui pourrait �tre transmis avec ce message. Ce message fait �galement l\u2019objet d\u2019un copyright. Il est interdit d\u2019en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement �crit du d�tenteur du copyright.
>>
>> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Hi, André
Thanks for the great explanation. So the current thread count will grow always until it reaches to the max configuration.
I have another strange thing:
We never monitored tomcat busy thread count high (we monitored one minutes interval through Nagios to get tomcat manager result, not high than 10). So if the threads grows, it should monitored the busy thread count reach that high(or some lower). So I'm still not understand when the current thread count will grow while current busy thread has not change a lot.
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Wednesday, January 18, 2017 9:41 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
Hi.
I believe that what Philippe mentions below is somewhat different : in his configuration, there is apparently a front-end httpd server, which communicates with Tomcat via AJP and the tomcat AJP Connector.
In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates a series of connections to the back-end tomcat, and keeps these connections alive in a pool of connections, according to rules which are different, than what applies to your case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
So Philippe's case introduces probably an additional level of complexity into the equation.
semi-graphically :
smith case :
client <- HTTP -> tomcat HTTP connector - tomcat thread
Philippe's case :
client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
The real question is :
The tomcat 8.0 HTTP Connector documentation
(http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) mentions a series of attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing the number of threads dynamically (increasing the number of threads (up to maxThreads) when needed to process simultaneous requests, and decreasing the number of threads again (down to minSpareThreads) when less requests are being processed).
According to observations however (and to Chris' comments), that does not seem to be the case : once the number of threads has grown to a certain number, it never goes down back down again.
It has to be said that the above interpretation was mine, and the current documentation of the HTTP Connector never says explicitly that, on its own, it manages the number of threads dynamically. But it *does* mention a minSpareThreads parameter.
On the other hand, when you use an Executor (http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation states explicitly that the number of threads *is* dynamically managed, up and down.
I found something else which seems to explain the riddle :
http://tomcat.apache.org/migration-6.html#Connector_thread_pools
That section explicitly says that since tomcat 6.0, for a Connector without an Executor, the number of threads always grows, and never decreases. And it also explicitly says that the Connector's "minSpareThreads" attribute will be ignored.
So in fact the only thing wrong, is the online documentation for the Connectors : the minSpareThreads attribute should be removed (since it is anyway ignored).
That seems to have been an oversight ever since tomcat 6.0.
As far as I am concerned thus, the mystery is solved.
One question which is a bit left open is :
What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle threads, as opposed to using an Executor to manage the number of threads dynamically ?
But that is probably the kind of question to which the appropriate answer is : "it depends.."
On 18.01.2017 07:33, smith wrote:
> Thanks, Philippe
>
> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>
> -----Original Message-----
> From: Philippe Busque [mailto:pbusque@mediagrif.com]
> Sent: Monday, January 16, 2017 8:09 PM
> To: users@tomcat.apache.org
> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>
> We're having a similar issues with our numberous Tomcat instances.
>
> Our connector config look like this.
>
> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="20000" URIEncoding="UTF-8" />
>
>
> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>
> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>
> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>
>
> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>
>
> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>
>
> Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
>> On 16.01.2017 11:10, smith wrote:
>>> We has same problem on dev env that no any traffic to the serive,
>>
>> Ah. That is /new/ information, which may change the suggestions below.
>> It looks like you should really find out what these threads are doing,
>> probably by doing a few thread dumps.
>> See here e.g. :
>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>
>> Again : we do not know your application, so we can only make guesses
>> based on the information that you provide.
>>
>> will try on dev first
>>>
>>> -----Original Message-----
>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Monday, January 16, 2017 10:08 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 16.01.2017 09:50, smith wrote:
>>>> Busy one is process customer request, do not know what non-busy one
>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>> will not cause so long connection
>>>>
>>>> -smith
>>>
>>> And did you actually try it ?
>>>
>>> We do not know your website or your application, so we cannot tell
>>> how many clients there are, what these clients are really requesting,
>>> how many requests each client is sending before going away, etc.
>>>
>>> KeepAlive means that when a client has sent its /last/ request and
>>> received the response, one thread is going to remain "not free" (but
>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>> client would still send another request (which it may never do,
>>> depending on the application).
>>>
>>> Imagine that your application is so that the average client
>>> - connects to your site
>>> - sends a single HTTP request, which gets processed in 0.1 s
>>> - receives the response
>>> - and then goes away
>>> and that the above sequence happens once every second, from different
>>> clients.
>>> After one second, there will be one thread waiting for another 19
>>> seconds before becoming free (and potentially destroyed or re-used).
>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>> but there will be 19 other threads still waiting, and one new thread
>>> just created.
>>> If everything stays perfectly regular like that, your will have
>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>> If you change the above so that there is a new client every 0.5 s,
>>> you will have permanently 40 threads (of which only 2 maximum are
>>> really doing something).
>>>
>>> The point is : KeepAlive is not "bad", and in some cases having a
>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>> having a high number of threads sitting idle is not necessarily a
>>> problem.
>>> Your own scenario is probably not like the above perfectly regular
>>> and irrealistic one above. But there may be a perfectly logical
>>> reason why you have so many threads on average, and I am just trying
>>> to give you ideas for finding out the reason.
>>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>
>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>> this parameter may has nothing to do with this
>>>>
>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>> and what are the non-busy ones doing ?
>>>>
>>>>
>>>>> --
>>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I can find nothing really wrong in your configuration below.
>>>>>> But, what happens if in this section :
>>>>>>
>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>> > redirectPort="8443" />
>>>>>>
>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>> the above 20 seconds) ?
>>>>>>
>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>
>>>>>> See :
>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>> Im
>>>>>> plementation
>>>>>> --> connectionTimeout
>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>
>>>>>>
>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>> The server.xml:
>>>>>>>
>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>> <!--
>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>> or more
>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>> distributed with
>>>>>>> this work for additional information regarding copyright
>>>>>>> ownership.
>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>> Version 2.0
>>>>>>> (the "License"); you may not use this file except in
>>>>>>> compliance with
>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>
>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>
>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>> software
>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>> BASIS,
>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>> express or implied.
>>>>>>> See the License for the specific language governing
>>>>>>> permissions and
>>>>>>> limitations under the License.
>>>>>>> -->
>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>> Documentation at /docs/config/server.html
>>>>>>> -->
>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>> <!-- Security listener. Documentation at
>>>>>>> /docs/config/listeners.html
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>> -->
>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>> SSLEngine="on" />
>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>> java/javax APIs-->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>> />
>>>>>>>
>>>>>>> <!-- Global JNDI resources
>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>> -->
>>>>>>> <GlobalNamingResources>
>>>>>>> <!-- Editable user database that can also be used by
>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>> -->
>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>> description="User database that can be updated
>>>>>>> and saved"
>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>> </GlobalNamingResources>
>>>>>>>
>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>> "Connectors" that share
>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>> a "Container",
>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>> at this level.
>>>>>>> Documentation at /docs/config/service.html
>>>>>>> -->
>>>>>>> <Service name="Catalina">
>>>>>>>
>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>> define one or more named thread pools-->
>>>>>>> <!--
>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>> namePrefix="catalina-exec-"
>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>> -->
>>>>>>>
>>>>>>>
>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>> requests are received
>>>>>>> and responses are returned. Documentation at :
>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>> (blocking & non-blocking)
>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>> -->
>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>> <!--
>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>> connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> -->
>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>> This connector uses the NIO implementation that
>>>>>>> requires the JSSE
>>>>>>> style configuration. When using the APR/native
>>>>>>> implementation, the
>>>>>>> OpenSSL style configuration is required as described
>>>>>>> in the APR/native
>>>>>>> documentation -->
>>>>>>> <!--
>>>>>>> <Connector port="8443"
>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>> scheme="https" secure="true"
>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>> redirectPort="8443" />
>>>>>>>
>>>>>>>
>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>> Catalina) that processes
>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>> stand alone
>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>> and passes them
>>>>>>> on to the appropriate Host (virtual host).
>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>
>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>> via AJP ie :
>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>> jvmRoute="jvm1">
>>>>>>> -->
>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>
>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>> at:
>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>> -->
>>>>>>> <!--
>>>>>>> <Cluster
>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>> user passwords
>>>>>>> via a brute-force attack -->
>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>> the global JNDI
>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>> that are performed against this UserDatabase are
>>>>>>> immediately
>>>>>>> available for use by the Realm. -->
>>>>>>> <Realm
>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>> resourceName="UserDatabase"/>
>>>>>>> </Realm>
>>>>>>>
>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>
>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>> web applications
>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>> <!--
>>>>>>> <Valve
>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Access log processes all example.
>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>> Note: The pattern used is equivalent to using
>>>>>>> pattern="common" -->
>>>>>>>
>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>> directory="logs"
>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>
>>>>>>> <Context path="" allowLinking="true"
>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>> </Host>
>>>>>>> </Engine>
>>>>>>> </Service>
>>>>>>> </Server>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>> To: 'users'
>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>
>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>
>>>>>>>> When will the thread reduce?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Smith
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>> look at it.
>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>> Often, the issue is in the details.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>
> Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
>
> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
Hi.
I believe that what Philippe mentions below is somewhat different : in his configuration,
there is apparently a front-end httpd server, which communicates with Tomcat via AJP and
the tomcat AJP Connector.
In such a case, the "mod_jk" or "mod_proxy_ajp" connector module inside of httpd, creates
a series of connections to the back-end tomcat, and keeps these connections alive in a
pool of connections, according to rules which are different, than what applies to your
case (which consists of direct HTTP connections from browsers, to the tomcat HTTP connector).
So Philippe's case introduces probably an additional level of complexity into the equation.
semi-graphically :
smith case :
client <- HTTP -> tomcat HTTP connector - tomcat thread
Philippe's case :
client <- HTTP -> apache httpd + ajp module <- AJP -> tomcat AJP connector - tomcat thread
The real question is :
The tomcat 8.0 HTTP Connector documentation
(http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) mentions a series of
attributes/parameters (maxThreads, minSpareThreads, connectionTimeout,
keepAliveTimeout,..) which, together, would lead one to believe that tomcat is managing
the number of threads dynamically (increasing the number of threads (up to maxThreads)
when needed to process simultaneous requests, and decreasing the number of threads again
(down to minSpareThreads) when less requests are being processed).
According to observations however (and to Chris' comments), that does not seem to be the
case : once the number of threads has grown to a certain number, it never goes down back
down again.
It has to be said that the above interpretation was mine, and the current documentation of
the HTTP Connector never says explicitly that, on its own, it manages the number of
threads dynamically. But it *does* mention a minSpareThreads parameter.
On the other hand, when you use an Executor
(http://tomcat.apache.org/tomcat-8.0-doc/config/executor.html), then the documentation
states explicitly that the number of threads *is* dynamically managed, up and down.
I found something else which seems to explain the riddle :
http://tomcat.apache.org/migration-6.html#Connector_thread_pools
That section explicitly says that since tomcat 6.0, for a Connector without an Executor,
the number of threads always grows, and never decreases. And it also explicitly says that
the Connector's "minSpareThreads" attribute will be ignored.
So in fact the only thing wrong, is the online documentation for the Connectors : the
minSpareThreads attribute should be removed (since it is anyway ignored).
That seems to have been an oversight ever since tomcat 6.0.
As far as I am concerned thus, the mystery is solved.
One question which is a bit left open is :
What - if any - is the real advantage/disadvantage of having perhaps maxThreads idle
threads, as opposed to using an Executor to manage the number of threads dynamically ?
But that is probably the kind of question to which the appropriate answer is : "it depends.."
On 18.01.2017 07:33, smith wrote:
> Thanks, Philippe
>
> But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
>
> -----Original Message-----
> From: Philippe Busque [mailto:pbusque@mediagrif.com]
> Sent: Monday, January 16, 2017 8:09 PM
> To: users@tomcat.apache.org
> Subject: Re: Re: FW: tomcat 8080 thread not reduced
>
> We're having a similar issues with our numberous Tomcat instances.
>
> Our connector config look like this.
>
> <Connector port="8910" protocol="AJP/1.3" maxThreads="200"
> enableLookups="false" redirectPort="8443" acceptCount="100"
> connectionTimeout="20000" URIEncoding="UTF-8" />
>
>
> Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
>
> Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
>
> I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
>
>
> As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
>
>
> This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
> But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
>
>
> Le 2017-01-16 � 05:24, Andr� Warnier (tomcat) a �crit :
>> On 16.01.2017 11:10, smith wrote:
>>> We has same problem on dev env that no any traffic to the serive,
>>
>> Ah. That is /new/ information, which may change the suggestions below.
>> It looks like you should really find out what these threads are doing,
>> probably by doing a few thread dumps.
>> See here e.g. :
>> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>>
>> Again : we do not know your application, so we can only make guesses
>> based on the information that you provide.
>>
>> will try on dev first
>>>
>>> -----Original Message-----
>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Monday, January 16, 2017 10:08 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 16.01.2017 09:50, smith wrote:
>>>> Busy one is process customer request, do not know what non-busy one
>>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>>> will not cause so long connection
>>>>
>>>> -smith
>>>
>>> And did you actually try it ?
>>>
>>> We do not know your website or your application, so we cannot tell
>>> how many clients there are, what these clients are really requesting,
>>> how many requests each client is sending before going away, etc.
>>>
>>> KeepAlive means that when a client has sent its /last/ request and
>>> received the response, one thread is going to remain "not free" (but
>>> doing nothing) for the duration of the KeepAlive timeout. This thread
>>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>>> client would still send another request (which it may never do,
>>> depending on the application).
>>>
>>> Imagine that your application is so that the average client
>>> - connects to your site
>>> - sends a single HTTP request, which gets processed in 0.1 s
>>> - receives the response
>>> - and then goes away
>>> and that the above sequence happens once every second, from different
>>> clients.
>>> After one second, there will be one thread waiting for another 19
>>> seconds before becoming free (and potentially destroyed or re-used).
>>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>>> threads. And so on. After 20 seconds, the first thread will be freed,
>>> but there will be 19 other threads still waiting, and one new thread
>>> just created.
>>> If everything stays perfectly regular like that, your will have
>>> /permanently/ 20 threads in existence, even if the minimum is 10.
>>> If you change the above so that there is a new client every 0.5 s,
>>> you will have permanently 40 threads (of which only 2 maximum are
>>> really doing something).
>>>
>>> The point is : KeepAlive is not "bad", and in some cases having a
>>> relatively long KeepAliveTimeout is the right thing to do. Also,
>>> having a high number of threads sitting idle is not necessarily a
>>> problem.
>>> Your own scenario is probably not like the above perfectly regular
>>> and irrealistic one above. But there may be a perfectly logical
>>> reason why you have so many threads on average, and I am just trying
>>> to give you ideas for finding out the reason.
>>>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Monday, January 16, 2017 8:33 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>>
>>>>> actually there is not much busy threads, less tahn 10,so i think
>>>>> this parameter may has nothing to do with this
>>>>
>>>> It depends on what you call "busy". What are the busy ones doing ?
>>>> and what are the non-busy ones doing ?
>>>>
>>>>
>>>>> --
>>>>> \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348 +08:00
>>>>> \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I can find nothing really wrong in your configuration below.
>>>>>> But, what happens if in this section :
>>>>>>
>>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>>> > redirectPort="8443" />
>>>>>>
>>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>>> the above 20 seconds) ?
>>>>>>
>>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>>
>>>>>> See :
>>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>>> Im
>>>>>> plementation
>>>>>> --> connectionTimeout
>>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>>
>>>>>>
>>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>>> The server.xml:
>>>>>>>
>>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>>> <!--
>>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>>> or more
>>>>>>> contributor license agreements. See the NOTICE file
>>>>>>> distributed with
>>>>>>> this work for additional information regarding copyright
>>>>>>> ownership.
>>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>>> Version 2.0
>>>>>>> (the "License"); you may not use this file except in
>>>>>>> compliance with
>>>>>>> the License. You may obtain a copy of the License at
>>>>>>>
>>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>>
>>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>>> software
>>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>>> BASIS,
>>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>>> express or implied.
>>>>>>> See the License for the specific language governing
>>>>>>> permissions and
>>>>>>> limitations under the License.
>>>>>>> -->
>>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>>> define subcomponents such as "Valves" at this level.
>>>>>>> Documentation at /docs/config/server.html
>>>>>>> -->
>>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>>> <!-- Security listener. Documentation at
>>>>>>> /docs/config/listeners.html
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>>> -->
>>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>>> SSLEngine="on" />
>>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>>> java/javax APIs-->
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>>> />
>>>>>>> <Listener
>>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>>> />
>>>>>>>
>>>>>>> <!-- Global JNDI resources
>>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>>> -->
>>>>>>> <GlobalNamingResources>
>>>>>>> <!-- Editable user database that can also be used by
>>>>>>> UserDatabaseRealm to authenticate users
>>>>>>> -->
>>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>>> description="User database that can be updated
>>>>>>> and saved"
>>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>>> </GlobalNamingResources>
>>>>>>>
>>>>>>> <!-- A "Service" is a collection of one or more
>>>>>>> "Connectors" that share
>>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>>> a "Container",
>>>>>>> so you may not define subcomponents such as "Valves"
>>>>>>> at this level.
>>>>>>> Documentation at /docs/config/service.html
>>>>>>> -->
>>>>>>> <Service name="Catalina">
>>>>>>>
>>>>>>> <!--The connectors can use a shared executor, you can
>>>>>>> define one or more named thread pools-->
>>>>>>> <!--
>>>>>>> <Executor name="tomcatThreadPool"
>>>>>>> namePrefix="catalina-exec-"
>>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>>> -->
>>>>>>>
>>>>>>>
>>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>>> requests are received
>>>>>>> and responses are returned. Documentation at :
>>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>>> (blocking & non-blocking)
>>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>>> -->
>>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>>> <!--
>>>>>>> <Connector executor="tomcatThreadPool"
>>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>>> connectionTimeout="20000"
>>>>>>> redirectPort="8443" />
>>>>>>> -->
>>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>>> This connector uses the NIO implementation that
>>>>>>> requires the JSSE
>>>>>>> style configuration. When using the APR/native
>>>>>>> implementation, the
>>>>>>> OpenSSL style configuration is required as described
>>>>>>> in the APR/native
>>>>>>> documentation -->
>>>>>>> <!--
>>>>>>> <Connector port="8443"
>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>>> scheme="https" secure="true"
>>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>>> redirectPort="8443" />
>>>>>>>
>>>>>>>
>>>>>>> <!-- An Engine represents the entry point (within
>>>>>>> Catalina) that processes
>>>>>>> every request. The Engine implementation for Tomcat
>>>>>>> stand alone
>>>>>>> analyzes the HTTP headers included with the request,
>>>>>>> and passes them
>>>>>>> on to the appropriate Host (virtual host).
>>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>>
>>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>>> via AJP ie :
>>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>>> jvmRoute="jvm1">
>>>>>>> -->
>>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>>
>>>>>>> <!--For clustering, please take a look at documentation
>>>>>>> at:
>>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>>> -->
>>>>>>> <!--
>>>>>>> <Cluster
>>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>>> user passwords
>>>>>>> via a brute-force attack -->
>>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>>> the global JNDI
>>>>>>> resources under the key "UserDatabase". Any edits
>>>>>>> that are performed against this UserDatabase are
>>>>>>> immediately
>>>>>>> available for use by the Realm. -->
>>>>>>> <Realm
>>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>>> resourceName="UserDatabase"/>
>>>>>>> </Realm>
>>>>>>>
>>>>>>> <Host name="localhost" appBase="webapps"
>>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>>
>>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>>> web applications
>>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>>> <!--
>>>>>>> <Valve
>>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>>> -->
>>>>>>>
>>>>>>> <!-- Access log processes all example.
>>>>>>> Documentation at: /docs/config/valve.html
>>>>>>> Note: The pattern used is equivalent to using
>>>>>>> pattern="common" -->
>>>>>>>
>>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>>> directory="logs"
>>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>>
>>>>>>> <Context path="" allowLinking="true"
>>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>>> </Host>
>>>>>>> </Engine>
>>>>>>> </Service>
>>>>>>> </Server>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>>> To: users@tomcat.apache.org
>>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>>> To: 'users'
>>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>>
>>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>>
>>>>>>>> When will the thread reduce?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Smith
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>>> (confidential things removed), so that we could have a useful
>>>>>>> look at it.
>>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>>> Often, the issue is in the details.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>
> Ce message et les fichiers d\u2019accompagnement transmis avec celui-ci s\u2019adressent express�ment au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privil�gi�s. Si vous recevez ce message par erreur, veuillez en aviser imm�diatement l\u2019exp�diteur par courrier �lectronique. Veuillez �galement ne pas en prendre connaissance et en supprimer toutes les copies imm�diatement. Technologies Interactives Mediagrif Inc. et ses filiales n\u2019acceptent aucune responsabilit� � l\u2019�gard des opinions exprim�es dans le message ou des cons�quences de tout virus informatique qui pourrait �tre transmis avec ce message. Ce message fait �galement l\u2019objet d\u2019un copyright. Il est interdit d\u2019en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement �crit du d�tenteur du copyright.
>
> This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Re: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Thanks, Philippe
But we never monitored tomcat busy thread count high (we monitored one minutes interval through nagios to get tomcat manager result, not high than 10). This is strange
-----Original Message-----
From: Philippe Busque [mailto:pbusque@mediagrif.com]
Sent: Monday, January 16, 2017 8:09 PM
To: users@tomcat.apache.org
Subject: Re: Re: FW: tomcat 8080 thread not reduced
We're having a similar issues with our numberous Tomcat instances.
Our connector config look like this.
<Connector port="8910" protocol="AJP/1.3" maxThreads="200"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" URIEncoding="UTF-8" />
Sometime, the number of active connection would jump very high (up to 190), due to some external issues (database lock, etc) and threads would accumulate.
Even though a connectionTimeout is set, and therefor set keepAliveTimeout as the same value, threads are never released once the problem is resolved until Tomcat is restarted. We would end up with maybe 5-10 busy workers, but 190 idle workers/ threads
I think the issue is related to how the StandardThreadExecutor is implemented. The StandardThreadExecutor is a front for the default Java ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is distributing work in round robin fashion among all defined workers, rather than sticking to the core threads.
As a result, should a website has any constant traffic (Apache AJP ping, load balancer monitoring, normal traffic, etc), all thread will be hit at least once within the configured keepAliveTimeout, reseting it. So unless the keepAliveTimeout is set to a very low value, which defeat the purpose, thread will never be released .
This is what I've come to suspect from looking at the StandardThreadExecutor, but never really had the opportunity to do deeper test with load.
But from Tomcat 6 to tomcat 8, we were never able to decrease the number of 'idle' workers back from the highest value it had reached.
Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
> On 16.01.2017 11:10, smith wrote:
>> We has same problem on dev env that no any traffic to the serive,
>
> Ah. That is /new/ information, which may change the suggestions below.
> It looks like you should really find out what these threads are doing,
> probably by doing a few thread dumps.
> See here e.g. :
> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>
> Again : we do not know your application, so we can only make guesses
> based on the information that you provide.
>
> will try on dev first
>>
>> -----Original Message-----
>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Monday, January 16, 2017 10:08 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> On 16.01.2017 09:50, smith wrote:
>>> Busy one is process customer request, do not know what non-busy one
>>> is doing, always keep 120 for many days. I don't think 20s timeout
>>> will not cause so long connection
>>>
>>> -smith
>>
>> And did you actually try it ?
>>
>> We do not know your website or your application, so we cannot tell
>> how many clients there are, what these clients are really requesting,
>> how many requests each client is sending before going away, etc.
>>
>> KeepAlive means that when a client has sent its /last/ request and
>> received the response, one thread is going to remain "not free" (but
>> doing nothing) for the duration of the KeepAlive timeout. This thread
>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>> client would still send another request (which it may never do,
>> depending on the application).
>>
>> Imagine that your application is so that the average client
>> - connects to your site
>> - sends a single HTTP request, which gets processed in 0.1 s
>> - receives the response
>> - and then goes away
>> and that the above sequence happens once every second, from different
>> clients.
>> After one second, there will be one thread waiting for another 19
>> seconds before becoming free (and potentially destroyed or re-used).
>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>> threads. And so on. After 20 seconds, the first thread will be freed,
>> but there will be 19 other threads still waiting, and one new thread
>> just created.
>> If everything stays perfectly regular like that, your will have
>> /permanently/ 20 threads in existence, even if the minimum is 10.
>> If you change the above so that there is a new client every 0.5 s,
>> you will have permanently 40 threads (of which only 2 maximum are
>> really doing something).
>>
>> The point is : KeepAlive is not "bad", and in some cases having a
>> relatively long KeepAliveTimeout is the right thing to do. Also,
>> having a high number of threads sitting idle is not necessarily a
>> problem.
>> Your own scenario is probably not like the above perfectly regular
>> and irrealistic one above. But there may be a perfectly logical
>> reason why you have so many threads on average, and I am just trying
>> to give you ideas for finding out the reason.
>>
>>
>>>
>>> -----Original Message-----
>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Monday, January 16, 2017 8:33 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>
>>>> actually there is not much busy threads, less tahn 10,so i think
>>>> this parameter may has nothing to do with this
>>>
>>> It depends on what you call "busy". What are the busy ones doing ?
>>> and what are the non-busy ones doing ?
>>>
>>>
>>>> --
>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>
>>>>> Hi.
>>>>>
>>>>> I can find nothing really wrong in your configuration below.
>>>>> But, what happens if in this section :
>>>>>
>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>> > redirectPort="8443" />
>>>>>
>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>> the above 20 seconds) ?
>>>>>
>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>
>>>>> See :
>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_
>>>>> Im
>>>>> plementation
>>>>> --> connectionTimeout
>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>
>>>>>
>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>> The server.xml:
>>>>>>
>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>> <!--
>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>> or more
>>>>>> contributor license agreements. See the NOTICE file
>>>>>> distributed with
>>>>>> this work for additional information regarding copyright
>>>>>> ownership.
>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>> Version 2.0
>>>>>> (the "License"); you may not use this file except in
>>>>>> compliance with
>>>>>> the License. You may obtain a copy of the License at
>>>>>>
>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>
>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>> software
>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>> BASIS,
>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>> express or implied.
>>>>>> See the License for the specific language governing
>>>>>> permissions and
>>>>>> limitations under the License.
>>>>>> -->
>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>> define subcomponents such as "Valves" at this level.
>>>>>> Documentation at /docs/config/server.html
>>>>>> -->
>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>> <Listener
>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>> <!-- Security listener. Documentation at
>>>>>> /docs/config/listeners.html
>>>>>> <Listener
>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>> -->
>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>> SSLEngine="on" />
>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>> java/javax APIs-->
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>> />
>>>>>> <Listener
>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>> />
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>> />
>>>>>>
>>>>>> <!-- Global JNDI resources
>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>> -->
>>>>>> <GlobalNamingResources>
>>>>>> <!-- Editable user database that can also be used by
>>>>>> UserDatabaseRealm to authenticate users
>>>>>> -->
>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>> description="User database that can be updated
>>>>>> and saved"
>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>> </GlobalNamingResources>
>>>>>>
>>>>>> <!-- A "Service" is a collection of one or more
>>>>>> "Connectors" that share
>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>> a "Container",
>>>>>> so you may not define subcomponents such as "Valves"
>>>>>> at this level.
>>>>>> Documentation at /docs/config/service.html
>>>>>> -->
>>>>>> <Service name="Catalina">
>>>>>>
>>>>>> <!--The connectors can use a shared executor, you can
>>>>>> define one or more named thread pools-->
>>>>>> <!--
>>>>>> <Executor name="tomcatThreadPool"
>>>>>> namePrefix="catalina-exec-"
>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>> -->
>>>>>>
>>>>>>
>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>> requests are received
>>>>>> and responses are returned. Documentation at :
>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>> (blocking & non-blocking)
>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>> -->
>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>> redirectPort="8443" />
>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>> <!--
>>>>>> <Connector executor="tomcatThreadPool"
>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>> connectionTimeout="20000"
>>>>>> redirectPort="8443" />
>>>>>> -->
>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>> This connector uses the NIO implementation that
>>>>>> requires the JSSE
>>>>>> style configuration. When using the APR/native
>>>>>> implementation, the
>>>>>> OpenSSL style configuration is required as described
>>>>>> in the APR/native
>>>>>> documentation -->
>>>>>> <!--
>>>>>> <Connector port="8443"
>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>> scheme="https" secure="true"
>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>> -->
>>>>>>
>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>> redirectPort="8443" />
>>>>>>
>>>>>>
>>>>>> <!-- An Engine represents the entry point (within
>>>>>> Catalina) that processes
>>>>>> every request. The Engine implementation for Tomcat
>>>>>> stand alone
>>>>>> analyzes the HTTP headers included with the request,
>>>>>> and passes them
>>>>>> on to the appropriate Host (virtual host).
>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>
>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>> via AJP ie :
>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>> jvmRoute="jvm1">
>>>>>> -->
>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>
>>>>>> <!--For clustering, please take a look at documentation
>>>>>> at:
>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>> -->
>>>>>> <!--
>>>>>> <Cluster
>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>> -->
>>>>>>
>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>> user passwords
>>>>>> via a brute-force attack -->
>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>> the global JNDI
>>>>>> resources under the key "UserDatabase". Any edits
>>>>>> that are performed against this UserDatabase are
>>>>>> immediately
>>>>>> available for use by the Realm. -->
>>>>>> <Realm
>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>> resourceName="UserDatabase"/>
>>>>>> </Realm>
>>>>>>
>>>>>> <Host name="localhost" appBase="webapps"
>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>
>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>> web applications
>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>> <!--
>>>>>> <Valve
>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>> -->
>>>>>>
>>>>>> <!-- Access log processes all example.
>>>>>> Documentation at: /docs/config/valve.html
>>>>>> Note: The pattern used is equivalent to using
>>>>>> pattern="common" -->
>>>>>>
>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>> directory="logs"
>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>
>>>>>> <Context path="" allowLinking="true"
>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>> </Host>
>>>>>> </Engine>
>>>>>> </Service>
>>>>>> </Server>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>> To: users@tomcat.apache.org
>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>
>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>> To: 'users'
>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>
>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>
>>>>>>> When will the thread reduce?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Smith
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>> (confidential things removed), so that we could have a useful
>>>>>> look at it.
>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>> Often, the issue is in the details.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> --- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Re: FW: tomcat 8080 thread not reduced
Posted by Philippe Busque <pb...@mediagrif.com>.
We're having a similar issues with our numberous Tomcat instances.
Our connector config look like this.
<Connector port="8910" protocol="AJP/1.3" maxThreads="200"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" URIEncoding="UTF-8" />
Sometime, the number of active connection would jump very high (up to
190), due to some external issues (database lock, etc) and threads would
accumulate.
Even though a connectionTimeout is set, and therefor set
keepAliveTimeout as the same value, threads are never released once the
problem is resolved until Tomcat is restarted. We would end up with
maybe 5-10 busy workers, but 190 idle workers/ threads
I think the issue is related to how the StandardThreadExecutor is
implemented. The StandardThreadExecutor is a front for the default Java
ThreadPoolExecutor. If I'm not mistaken, ThreadPoolExecutor is
distributing work in round robin fashion among all defined workers,
rather than sticking to the core threads.
As a result, should a website has any constant traffic (Apache AJP ping,
load balancer monitoring, normal traffic, etc), all thread will be hit
at least once within the configured keepAliveTimeout, reseting it. So
unless the keepAliveTimeout is set to a very low value, which defeat the
purpose, thread will never be released .
This is what I've come to suspect from looking at the
StandardThreadExecutor, but never really had the opportunity to do
deeper test with load.
But from Tomcat 6 to tomcat 8, we were never able to decrease the
number of 'idle' workers back from the highest value it had reached.
Le 2017-01-16 à 05:24, André Warnier (tomcat) a écrit :
> On 16.01.2017 11:10, smith wrote:
>> We has same problem on dev env that no any traffic to the serive,
>
> Ah. That is /new/ information, which may change the suggestions below.
> It looks like you should really find out what these threads are doing,
> probably by doing a few thread dumps.
> See here e.g. :
> http://stackoverflow.com/questions/18573411/tomcat-thread-dump
>
> Again : we do not know your application, so we can only make guesses
> based on the information that you provide.
>
> will try on dev first
>>
>> -----Original Message-----
>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Monday, January 16, 2017 10:08 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> On 16.01.2017 09:50, smith wrote:
>>> Busy one is process customer request, do not know what non-busy one is
>>> doing, always keep 120 for many days. I don't think 20s timeout will
>>> not cause so long connection
>>>
>>> -smith
>>
>> And did you actually try it ?
>>
>> We do not know your website or your application, so we cannot tell
>> how many clients there are, what these clients are really requesting,
>> how many requests each client is sending before going away, etc.
>>
>> KeepAlive means that when a client has sent its /last/ request and
>> received the response, one thread is going to remain "not free" (but
>> doing nothing) for the duration of the KeepAlive timeout. This thread
>> will keep waiting, for KeepAliveTimeout seconds, just in case the
>> client would still send another request (which it may never do,
>> depending on the application).
>>
>> Imagine that your application is so that the average client
>> - connects to your site
>> - sends a single HTTP request, which gets processed in 0.1 s
>> - receives the response
>> - and then goes away
>> and that the above sequence happens once every second, from different
>> clients.
>> After one second, there will be one thread waiting for another 19
>> seconds before becoming free (and potentially destroyed or re-used).
>> After 2 seconds, there will be 2 such threads. After 3 seconds, 3
>> threads. And so on. After 20 seconds, the first thread will be freed,
>> but there will be 19 other threads still waiting, and one new thread
>> just created.
>> If everything stays perfectly regular like that, your will have
>> /permanently/ 20 threads in existence, even if the minimum is 10.
>> If you change the above so that there is a new client every 0.5 s,
>> you will have permanently 40 threads (of which only 2 maximum are
>> really doing something).
>>
>> The point is : KeepAlive is not "bad", and in some cases having a
>> relatively long KeepAliveTimeout is the right thing to do. Also,
>> having a high number of threads sitting idle is not necessarily a
>> problem.
>> Your own scenario is probably not like the above perfectly regular
>> and irrealistic one above. But there may be a perfectly logical
>> reason why you have so many threads on average, and I am just trying
>> to give you ideas for finding out the reason.
>>
>>
>>>
>>> -----Original Message-----
>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Monday, January 16, 2017 8:33 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 16.01.2017 03:41, Smith Hua wrote:
>>>>
>>>> actually there is not much busy threads, less tahn 10,so i think this
>>>> parameter may has nothing to do with this
>>>
>>> It depends on what you call "busy". What are the busy ones doing ?
>>> and what are the non-busy ones doing ?
>>>
>>>
>>>> --
>>>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00
>>>> 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>>>
>>>>> Hi.
>>>>>
>>>>> I can find nothing really wrong in your configuration below.
>>>>> But, what happens if in this section :
>>>>>
>>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>>> > maxThreads="300" connectionTimeout="20000"
>>>>> > redirectPort="8443" />
>>>>>
>>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of
>>>>> the above 20 seconds) ?
>>>>>
>>>>> Do you still see the number of threads remaining at the maximum ?
>>>>>
>>>>> See :
>>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Im
>>>>> plementation
>>>>> --> connectionTimeout
>>>>> and the fact that it is also the default for keepAliveTimeout
>>>>>
>>>>>
>>>>> On 14.01.2017 07:30, smith wrote:
>>>>>> The server.xml:
>>>>>>
>>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>>> <!--
>>>>>> Licensed to the Apache Software Foundation (ASF) under one
>>>>>> or more
>>>>>> contributor license agreements. See the NOTICE file
>>>>>> distributed with
>>>>>> this work for additional information regarding copyright
>>>>>> ownership.
>>>>>> The ASF licenses this file to You under the Apache License,
>>>>>> Version 2.0
>>>>>> (the "License"); you may not use this file except in
>>>>>> compliance with
>>>>>> the License. You may obtain a copy of the License at
>>>>>>
>>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>>
>>>>>> Unless required by applicable law or agreed to in writing,
>>>>>> software
>>>>>> distributed under the License is distributed on an "AS IS"
>>>>>> BASIS,
>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
>>>>>> express or implied.
>>>>>> See the License for the specific language governing
>>>>>> permissions and
>>>>>> limitations under the License.
>>>>>> -->
>>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>>> define subcomponents such as "Valves" at this level.
>>>>>> Documentation at /docs/config/server.html
>>>>>> -->
>>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>>> <Listener
>>>>>> className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>>> <!-- Security listener. Documentation at
>>>>>> /docs/config/listeners.html
>>>>>> <Listener
>>>>>> className="org.apache.catalina.security.SecurityListener" />
>>>>>> -->
>>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.AprLifecycleListener"
>>>>>> SSLEngine="on" />
>>>>>> <!-- Prevent memory leaks due to use of particular
>>>>>> java/javax APIs-->
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
>>>>>> />
>>>>>> <Listener
>>>>>> className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"
>>>>>> />
>>>>>> <Listener
>>>>>> className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"
>>>>>> />
>>>>>>
>>>>>> <!-- Global JNDI resources
>>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>>> -->
>>>>>> <GlobalNamingResources>
>>>>>> <!-- Editable user database that can also be used by
>>>>>> UserDatabaseRealm to authenticate users
>>>>>> -->
>>>>>> <Resource name="UserDatabase" auth="Container"
>>>>>> type="org.apache.catalina.UserDatabase"
>>>>>> description="User database that can be updated
>>>>>> and saved"
>>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>>> pathname="conf/tomcat-users.xml" />
>>>>>> </GlobalNamingResources>
>>>>>>
>>>>>> <!-- A "Service" is a collection of one or more
>>>>>> "Connectors" that share
>>>>>> a single "Container" Note: A "Service" is not itself
>>>>>> a "Container",
>>>>>> so you may not define subcomponents such as "Valves"
>>>>>> at this level.
>>>>>> Documentation at /docs/config/service.html
>>>>>> -->
>>>>>> <Service name="Catalina">
>>>>>>
>>>>>> <!--The connectors can use a shared executor, you can
>>>>>> define one or more named thread pools-->
>>>>>> <!--
>>>>>> <Executor name="tomcatThreadPool"
>>>>>> namePrefix="catalina-exec-"
>>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>>> -->
>>>>>>
>>>>>>
>>>>>> <!-- A "Connector" represents an endpoint by which
>>>>>> requests are received
>>>>>> and responses are returned. Documentation at :
>>>>>> Java HTTP Connector: /docs/config/http.html
>>>>>> (blocking & non-blocking)
>>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>>> -->
>>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>>> maxThreads="300" connectionTimeout="20000"
>>>>>> redirectPort="8443" />
>>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>>> <!--
>>>>>> <Connector executor="tomcatThreadPool"
>>>>>> port="8080" protocol="HTTP/1.1"
>>>>>> connectionTimeout="20000"
>>>>>> redirectPort="8443" />
>>>>>> -->
>>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>>> This connector uses the NIO implementation that
>>>>>> requires the JSSE
>>>>>> style configuration. When using the APR/native
>>>>>> implementation, the
>>>>>> OpenSSL style configuration is required as described
>>>>>> in the APR/native
>>>>>> documentation -->
>>>>>> <!--
>>>>>> <Connector port="8443"
>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>> maxThreads="150" SSLEnabled="true"
>>>>>> scheme="https" secure="true"
>>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>>> -->
>>>>>>
>>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>>> <Connector port="8009" protocol="AJP/1.3"
>>>>>> redirectPort="8443" />
>>>>>>
>>>>>>
>>>>>> <!-- An Engine represents the entry point (within
>>>>>> Catalina) that processes
>>>>>> every request. The Engine implementation for Tomcat
>>>>>> stand alone
>>>>>> analyzes the HTTP headers included with the request,
>>>>>> and passes them
>>>>>> on to the appropriate Host (virtual host).
>>>>>> Documentation at /docs/config/engine.html -->
>>>>>>
>>>>>> <!-- You should set jvmRoute to support load-balancing
>>>>>> via AJP ie :
>>>>>> <Engine name="Catalina" defaultHost="localhost"
>>>>>> jvmRoute="jvm1">
>>>>>> -->
>>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>>
>>>>>> <!--For clustering, please take a look at documentation
>>>>>> at:
>>>>>> /docs/cluster-howto.html (simple how to)
>>>>>> /docs/config/cluster.html (reference documentation)
>>>>>> -->
>>>>>> <!--
>>>>>> <Cluster
>>>>>> className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>>> -->
>>>>>>
>>>>>> <!-- Use the LockOutRealm to prevent attempts to guess
>>>>>> user passwords
>>>>>> via a brute-force attack -->
>>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>>> <!-- This Realm uses the UserDatabase configured in
>>>>>> the global JNDI
>>>>>> resources under the key "UserDatabase". Any edits
>>>>>> that are performed against this UserDatabase are
>>>>>> immediately
>>>>>> available for use by the Realm. -->
>>>>>> <Realm
>>>>>> className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>>> resourceName="UserDatabase"/>
>>>>>> </Realm>
>>>>>>
>>>>>> <Host name="localhost" appBase="webapps"
>>>>>> unpackWARs="true" autoDeploy="true">
>>>>>>
>>>>>> <!-- SingleSignOn valve, share authentication between
>>>>>> web applications
>>>>>> Documentation at: /docs/config/valve.html -->
>>>>>> <!--
>>>>>> <Valve
>>>>>> className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>>> -->
>>>>>>
>>>>>> <!-- Access log processes all example.
>>>>>> Documentation at: /docs/config/valve.html
>>>>>> Note: The pattern used is equivalent to using
>>>>>> pattern="common" -->
>>>>>>
>>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>>>>>> directory="logs"
>>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>>
>>>>>> <Context path="" allowLinking="true"
>>>>>> crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>>> </Host>
>>>>>> </Engine>
>>>>>> </Service>
>>>>>> </Server>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>>> To: users@tomcat.apache.org
>>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>>
>>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>>> To: 'users'
>>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one
>>>>>>> period of time, the thread count for 8080(our port published)
>>>>>>> goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>>
>>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is
>>>>>>> idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>>
>>>>>>> When will the thread reduce?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Smith
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> Please copy/paste your complete server.xml configuration file
>>>>>> (confidential things removed), so that we could have a useful
>>>>>> look at it.
>>>>>> Please edit *only* the confidential things, not entire sections.
>>>>>> Often, the issue is in the details.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright.
This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 16.01.2017 11:10, smith wrote:
> We has same problem on dev env that no any traffic to the serive,
Ah. That is /new/ information, which may change the suggestions below.
It looks like you should really find out what these threads are doing, probably by doing a
few thread dumps.
See here e.g. : http://stackoverflow.com/questions/18573411/tomcat-thread-dump
Again : we do not know your application, so we can only make guesses based on the
information that you provide.
will try on dev first
>
> -----Original Message-----
> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Monday, January 16, 2017 10:08 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> On 16.01.2017 09:50, smith wrote:
>> Busy one is process customer request, do not know what non-busy one is
>> doing, always keep 120 for many days. I don't think 20s timeout will
>> not cause so long connection
>>
>> -smith
>
> And did you actually try it ?
>
> We do not know your website or your application, so we cannot tell how many clients there are, what these clients are really requesting, how many requests each client is sending before going away, etc.
>
> KeepAlive means that when a client has sent its /last/ request and received the response, one thread is going to remain "not free" (but doing nothing) for the duration of the KeepAlive timeout. This thread will keep waiting, for KeepAliveTimeout seconds, just in case the client would still send another request (which it may never do, depending on the application).
>
> Imagine that your application is so that the average client
> - connects to your site
> - sends a single HTTP request, which gets processed in 0.1 s
> - receives the response
> - and then goes away
> and that the above sequence happens once every second, from different clients.
> After one second, there will be one thread waiting for another 19 seconds before becoming free (and potentially destroyed or re-used). After 2 seconds, there will be 2 such threads. After 3 seconds, 3 threads. And so on. After 20 seconds, the first thread will be freed, but there will be 19 other threads still waiting, and one new thread just created.
> If everything stays perfectly regular like that, your will have /permanently/ 20 threads in existence, even if the minimum is 10.
> If you change the above so that there is a new client every 0.5 s, you will have permanently 40 threads (of which only 2 maximum are really doing something).
>
> The point is : KeepAlive is not "bad", and in some cases having a relatively long KeepAliveTimeout is the right thing to do. Also, having a high number of threads sitting idle is not necessarily a problem.
> Your own scenario is probably not like the above perfectly regular and irrealistic one above. But there may be a perfectly logical reason why you have so many threads on average, and I am just trying to give you ideas for finding out the reason.
>
>
>>
>> -----Original Message-----
>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Monday, January 16, 2017 8:33 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> On 16.01.2017 03:41, Smith Hua wrote:
>>>
>>> actually there is not much busy threads, less tahn 10,so i think this
>>> parameter may has nothing to do with this
>>
>> It depends on what you call "busy". What are the busy ones doing ? and what are the non-busy ones doing ?
>>
>>
>>> --
>>> \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348 +08:00 \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>>>
>>>> Hi.
>>>>
>>>> I can find nothing really wrong in your configuration below.
>>>> But, what happens if in this section :
>>>>
>>>> > <Connector port="8080" protocol="HTTP/1.1"
>>>> > maxThreads="300" connectionTimeout="20000"
>>>> > redirectPort="8443" />
>>>>
>>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>>>>
>>>> Do you still see the number of threads remaining at the maximum ?
>>>>
>>>> See :
>>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Im
>>>> plementation
>>>> --> connectionTimeout
>>>> and the fact that it is also the default for keepAliveTimeout
>>>>
>>>>
>>>> On 14.01.2017 07:30, smith wrote:
>>>>> The server.xml:
>>>>>
>>>>> <?xml version='1.0' encoding='utf-8'?>
>>>>> <!--
>>>>> Licensed to the Apache Software Foundation (ASF) under one or more
>>>>> contributor license agreements. See the NOTICE file distributed with
>>>>> this work for additional information regarding copyright ownership.
>>>>> The ASF licenses this file to You under the Apache License, Version 2.0
>>>>> (the "License"); you may not use this file except in compliance with
>>>>> the License. You may obtain a copy of the License at
>>>>>
>>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>>
>>>>> Unless required by applicable law or agreed to in writing, software
>>>>> distributed under the License is distributed on an "AS IS" BASIS,
>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>>>> See the License for the specific language governing permissions and
>>>>> limitations under the License.
>>>>> -->
>>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>>> define subcomponents such as "Valves" at this level.
>>>>> Documentation at /docs/config/server.html
>>>>> -->
>>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>>>>> <!-- Security listener. Documentation at /docs/config/listeners.html
>>>>> <Listener className="org.apache.catalina.security.SecurityListener" />
>>>>> -->
>>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>>>>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>>>>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>>>>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>>>>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>>>>
>>>>> <!-- Global JNDI resources
>>>>> Documentation at /docs/jndi-resources-howto.html
>>>>> -->
>>>>> <GlobalNamingResources>
>>>>> <!-- Editable user database that can also be used by
>>>>> UserDatabaseRealm to authenticate users
>>>>> -->
>>>>> <Resource name="UserDatabase" auth="Container"
>>>>> type="org.apache.catalina.UserDatabase"
>>>>> description="User database that can be updated and saved"
>>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>>> pathname="conf/tomcat-users.xml" />
>>>>> </GlobalNamingResources>
>>>>>
>>>>> <!-- A "Service" is a collection of one or more "Connectors" that share
>>>>> a single "Container" Note: A "Service" is not itself a "Container",
>>>>> so you may not define subcomponents such as "Valves" at this level.
>>>>> Documentation at /docs/config/service.html
>>>>> -->
>>>>> <Service name="Catalina">
>>>>>
>>>>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>>>>> <!--
>>>>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>>>>> maxThreads="150" minSpareThreads="4"/>
>>>>> -->
>>>>>
>>>>>
>>>>> <!-- A "Connector" represents an endpoint by which requests are received
>>>>> and responses are returned. Documentation at :
>>>>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>>>>> Java AJP Connector: /docs/config/ajp.html
>>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>>> -->
>>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>>> maxThreads="300" connectionTimeout="20000"
>>>>> redirectPort="8443" />
>>>>> <!-- A "Connector" using the shared thread pool-->
>>>>> <!--
>>>>> <Connector executor="tomcatThreadPool"
>>>>> port="8080" protocol="HTTP/1.1"
>>>>> connectionTimeout="20000"
>>>>> redirectPort="8443" />
>>>>> -->
>>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>>> This connector uses the NIO implementation that requires the JSSE
>>>>> style configuration. When using the APR/native implementation, the
>>>>> OpenSSL style configuration is required as described in the APR/native
>>>>> documentation -->
>>>>> <!--
>>>>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>>>>> clientAuth="false" sslProtocol="TLS" />
>>>>> -->
>>>>>
>>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>>>>
>>>>>
>>>>> <!-- An Engine represents the entry point (within Catalina) that processes
>>>>> every request. The Engine implementation for Tomcat stand alone
>>>>> analyzes the HTTP headers included with the request, and passes them
>>>>> on to the appropriate Host (virtual host).
>>>>> Documentation at /docs/config/engine.html -->
>>>>>
>>>>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>>> -->
>>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>>
>>>>> <!--For clustering, please take a look at documentation at:
>>>>> /docs/cluster-howto.html (simple how to)
>>>>> /docs/config/cluster.html (reference documentation) -->
>>>>> <!--
>>>>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>>> -->
>>>>>
>>>>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>>>>> via a brute-force attack -->
>>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>>>>> resources under the key "UserDatabase". Any edits
>>>>> that are performed against this UserDatabase are immediately
>>>>> available for use by the Realm. -->
>>>>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>>>>> resourceName="UserDatabase"/>
>>>>> </Realm>
>>>>>
>>>>> <Host name="localhost" appBase="webapps"
>>>>> unpackWARs="true" autoDeploy="true">
>>>>>
>>>>> <!-- SingleSignOn valve, share authentication between web applications
>>>>> Documentation at: /docs/config/valve.html -->
>>>>> <!--
>>>>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>>>>> -->
>>>>>
>>>>> <!-- Access log processes all example.
>>>>> Documentation at: /docs/config/valve.html
>>>>> Note: The pattern used is equivalent to using pattern="common" -->
>>>>>
>>>>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>>>>> prefix="localhost_access_log" suffix=".txt"
>>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>>
>>>>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>>> </Host>
>>>>> </Engine>
>>>>> </Service>
>>>>> </Server>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>>> To: users@tomcat.apache.org
>>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>>
>>>>> On 13.01.2017 09:38, smith wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>>> To: 'users'
>>>>>> Subject: tomcat 8080 thread not reduced
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>>>>
>>>>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>>
>>>>>> When will the thread reduce?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Smith
>>>>>>
>>>>>>
>>>>>
>>>>> Hi.
>>>>>
>>>>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>>>>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
We has same problem on dev env that no any traffic to the serive, will try on dev first
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Monday, January 16, 2017 10:08 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 16.01.2017 09:50, smith wrote:
> Busy one is process customer request, do not know what non-busy one is
> doing, always keep 120 for many days. I don't think 20s timeout will
> not cause so long connection
>
> -smith
And did you actually try it ?
We do not know your website or your application, so we cannot tell how many clients there are, what these clients are really requesting, how many requests each client is sending before going away, etc.
KeepAlive means that when a client has sent its /last/ request and received the response, one thread is going to remain "not free" (but doing nothing) for the duration of the KeepAlive timeout. This thread will keep waiting, for KeepAliveTimeout seconds, just in case the client would still send another request (which it may never do, depending on the application).
Imagine that your application is so that the average client
- connects to your site
- sends a single HTTP request, which gets processed in 0.1 s
- receives the response
- and then goes away
and that the above sequence happens once every second, from different clients.
After one second, there will be one thread waiting for another 19 seconds before becoming free (and potentially destroyed or re-used). After 2 seconds, there will be 2 such threads. After 3 seconds, 3 threads. And so on. After 20 seconds, the first thread will be freed, but there will be 19 other threads still waiting, and one new thread just created.
If everything stays perfectly regular like that, your will have /permanently/ 20 threads in existence, even if the minimum is 10.
If you change the above so that there is a new client every 0.5 s, you will have permanently 40 threads (of which only 2 maximum are really doing something).
The point is : KeepAlive is not "bad", and in some cases having a relatively long KeepAliveTimeout is the right thing to do. Also, having a high number of threads sitting idle is not necessarily a problem.
Your own scenario is probably not like the above perfectly regular and irrealistic one above. But there may be a perfectly logical reason why you have so many threads on average, and I am just trying to give you ideas for finding out the reason.
>
> -----Original Message-----
> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Monday, January 16, 2017 8:33 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> On 16.01.2017 03:41, Smith Hua wrote:
>>
>> actually there is not much busy threads, less tahn 10,so i think this
>> parameter may has nothing to do with this
>
> It depends on what you call "busy". What are the busy ones doing ? and what are the non-busy ones doing ?
>
>
>> --
>> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00 发件人 André Warnier (tomcat) aw@ice-sa.com :
>>
>>> Hi.
>>>
>>> I can find nothing really wrong in your configuration below.
>>> But, what happens if in this section :
>>>
>>> > <Connector port="8080" protocol="HTTP/1.1"
>>> > maxThreads="300" connectionTimeout="20000"
>>> > redirectPort="8443" />
>>>
>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>>>
>>> Do you still see the number of threads remaining at the maximum ?
>>>
>>> See :
>>> http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Im
>>> plementation
>>> --> connectionTimeout
>>> and the fact that it is also the default for keepAliveTimeout
>>>
>>>
>>> On 14.01.2017 07:30, smith wrote:
>>>> The server.xml:
>>>>
>>>> <?xml version='1.0' encoding='utf-8'?>
>>>> <!--
>>>> Licensed to the Apache Software Foundation (ASF) under one or more
>>>> contributor license agreements. See the NOTICE file distributed with
>>>> this work for additional information regarding copyright ownership.
>>>> The ASF licenses this file to You under the Apache License, Version 2.0
>>>> (the "License"); you may not use this file except in compliance with
>>>> the License. You may obtain a copy of the License at
>>>>
>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>
>>>> Unless required by applicable law or agreed to in writing, software
>>>> distributed under the License is distributed on an "AS IS" BASIS,
>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>>> See the License for the specific language governing permissions and
>>>> limitations under the License.
>>>> -->
>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>> define subcomponents such as "Valves" at this level.
>>>> Documentation at /docs/config/server.html
>>>> -->
>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>>>> <!-- Security listener. Documentation at /docs/config/listeners.html
>>>> <Listener className="org.apache.catalina.security.SecurityListener" />
>>>> -->
>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>>>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>>>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>>>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>>>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>>>
>>>> <!-- Global JNDI resources
>>>> Documentation at /docs/jndi-resources-howto.html
>>>> -->
>>>> <GlobalNamingResources>
>>>> <!-- Editable user database that can also be used by
>>>> UserDatabaseRealm to authenticate users
>>>> -->
>>>> <Resource name="UserDatabase" auth="Container"
>>>> type="org.apache.catalina.UserDatabase"
>>>> description="User database that can be updated and saved"
>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>> pathname="conf/tomcat-users.xml" />
>>>> </GlobalNamingResources>
>>>>
>>>> <!-- A "Service" is a collection of one or more "Connectors" that share
>>>> a single "Container" Note: A "Service" is not itself a "Container",
>>>> so you may not define subcomponents such as "Valves" at this level.
>>>> Documentation at /docs/config/service.html
>>>> -->
>>>> <Service name="Catalina">
>>>>
>>>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>>>> <!--
>>>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>>>> maxThreads="150" minSpareThreads="4"/>
>>>> -->
>>>>
>>>>
>>>> <!-- A "Connector" represents an endpoint by which requests are received
>>>> and responses are returned. Documentation at :
>>>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>>>> Java AJP Connector: /docs/config/ajp.html
>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>> -->
>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>> maxThreads="300" connectionTimeout="20000"
>>>> redirectPort="8443" />
>>>> <!-- A "Connector" using the shared thread pool-->
>>>> <!--
>>>> <Connector executor="tomcatThreadPool"
>>>> port="8080" protocol="HTTP/1.1"
>>>> connectionTimeout="20000"
>>>> redirectPort="8443" />
>>>> -->
>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>> This connector uses the NIO implementation that requires the JSSE
>>>> style configuration. When using the APR/native implementation, the
>>>> OpenSSL style configuration is required as described in the APR/native
>>>> documentation -->
>>>> <!--
>>>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>>>> clientAuth="false" sslProtocol="TLS" />
>>>> -->
>>>>
>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>>>
>>>>
>>>> <!-- An Engine represents the entry point (within Catalina) that processes
>>>> every request. The Engine implementation for Tomcat stand alone
>>>> analyzes the HTTP headers included with the request, and passes them
>>>> on to the appropriate Host (virtual host).
>>>> Documentation at /docs/config/engine.html -->
>>>>
>>>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>> -->
>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>
>>>> <!--For clustering, please take a look at documentation at:
>>>> /docs/cluster-howto.html (simple how to)
>>>> /docs/config/cluster.html (reference documentation) -->
>>>> <!--
>>>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>> -->
>>>>
>>>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>>>> via a brute-force attack -->
>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>>>> resources under the key "UserDatabase". Any edits
>>>> that are performed against this UserDatabase are immediately
>>>> available for use by the Realm. -->
>>>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>>>> resourceName="UserDatabase"/>
>>>> </Realm>
>>>>
>>>> <Host name="localhost" appBase="webapps"
>>>> unpackWARs="true" autoDeploy="true">
>>>>
>>>> <!-- SingleSignOn valve, share authentication between web applications
>>>> Documentation at: /docs/config/valve.html -->
>>>> <!--
>>>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>>>> -->
>>>>
>>>> <!-- Access log processes all example.
>>>> Documentation at: /docs/config/valve.html
>>>> Note: The pattern used is equivalent to using pattern="common" -->
>>>>
>>>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>>>> prefix="localhost_access_log" suffix=".txt"
>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>
>>>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>> </Host>
>>>> </Engine>
>>>> </Service>
>>>> </Server>
>>>>
>>>> -----Original Message-----
>>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 13.01.2017 09:38, smith wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>> To: 'users'
>>>>> Subject: tomcat 8080 thread not reduced
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>>>
>>>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>
>>>>> When will the thread reduce?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Best regards
>>>>>
>>>>> Smith
>>>>>
>>>>>
>>>>
>>>> Hi.
>>>>
>>>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>>>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 16.01.2017 09:50, smith wrote:
> Busy one is process customer request, do not know what non-busy one is doing, always keep 120 for many days. I don't think 20s timeout will not cause so long connection
>
> -smith
And did you actually try it ?
We do not know your website or your application, so we cannot tell how many clients there
are, what these clients are really requesting, how many requests each client is sending
before going away, etc.
KeepAlive means that when a client has sent its /last/ request and received the response,
one thread is going to remain "not free" (but doing nothing) for the duration of the
KeepAlive timeout. This thread will keep waiting, for KeepAliveTimeout seconds, just in
case the client would still send another request (which it may never do, depending on the
application).
Imagine that your application is so that the average client
- connects to your site
- sends a single HTTP request, which gets processed in 0.1 s
- receives the response
- and then goes away
and that the above sequence happens once every second, from different clients.
After one second, there will be one thread waiting for another 19 seconds before becoming
free (and potentially destroyed or re-used). After 2 seconds, there will be 2 such
threads. After 3 seconds, 3 threads. And so on. After 20 seconds, the first thread will be
freed, but there will be 19 other threads still waiting, and one new thread just created.
If everything stays perfectly regular like that, your will have /permanently/ 20 threads
in existence, even if the minimum is 10.
If you change the above so that there is a new client every 0.5 s, you will have
permanently 40 threads (of which only 2 maximum are really doing something).
The point is : KeepAlive is not "bad", and in some cases having a relatively long
KeepAliveTimeout is the right thing to do. Also, having a high number of threads sitting
idle is not necessarily a problem.
Your own scenario is probably not like the above perfectly regular and irrealistic one
above. But there may be a perfectly logical reason why you have so many threads on
average, and I am just trying to give you ideas for finding out the reason.
>
> -----Original Message-----
> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Monday, January 16, 2017 8:33 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> On 16.01.2017 03:41, Smith Hua wrote:
>>
>> actually there is not much busy threads, less tahn 10,so i think this
>> parameter may has nothing to do with this
>
> It depends on what you call "busy". What are the busy ones doing ? and what are the non-busy ones doing ?
>
>
>> --
>> \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348 +08:00 \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>>
>>> Hi.
>>>
>>> I can find nothing really wrong in your configuration below.
>>> But, what happens if in this section :
>>>
>>> > <Connector port="8080" protocol="HTTP/1.1"
>>> > maxThreads="300" connectionTimeout="20000"
>>> > redirectPort="8443" />
>>>
>>> you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>>>
>>> Do you still see the number of threads remaining at the maximum ?
>>>
>>> See : http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
>>> --> connectionTimeout
>>> and the fact that it is also the default for
>>> keepAliveTimeout
>>>
>>>
>>> On 14.01.2017 07:30, smith wrote:
>>>> The server.xml:
>>>>
>>>> <?xml version='1.0' encoding='utf-8'?>
>>>> <!--
>>>> Licensed to the Apache Software Foundation (ASF) under one or more
>>>> contributor license agreements. See the NOTICE file distributed with
>>>> this work for additional information regarding copyright ownership.
>>>> The ASF licenses this file to You under the Apache License, Version 2.0
>>>> (the "License"); you may not use this file except in compliance with
>>>> the License. You may obtain a copy of the License at
>>>>
>>>> http://www.apache.org/licenses/LICENSE-2.0
>>>>
>>>> Unless required by applicable law or agreed to in writing, software
>>>> distributed under the License is distributed on an "AS IS" BASIS,
>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>>> See the License for the specific language governing permissions and
>>>> limitations under the License.
>>>> -->
>>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>>> define subcomponents such as "Valves" at this level.
>>>> Documentation at /docs/config/server.html
>>>> -->
>>>> <Server port="8005" shutdown="SHUTDOWN">
>>>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>>>> <!-- Security listener. Documentation at /docs/config/listeners.html
>>>> <Listener className="org.apache.catalina.security.SecurityListener" />
>>>> -->
>>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>>>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>>>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>>>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>>>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>>>
>>>> <!-- Global JNDI resources
>>>> Documentation at /docs/jndi-resources-howto.html
>>>> -->
>>>> <GlobalNamingResources>
>>>> <!-- Editable user database that can also be used by
>>>> UserDatabaseRealm to authenticate users
>>>> -->
>>>> <Resource name="UserDatabase" auth="Container"
>>>> type="org.apache.catalina.UserDatabase"
>>>> description="User database that can be updated and saved"
>>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>>> pathname="conf/tomcat-users.xml" />
>>>> </GlobalNamingResources>
>>>>
>>>> <!-- A "Service" is a collection of one or more "Connectors" that share
>>>> a single "Container" Note: A "Service" is not itself a "Container",
>>>> so you may not define subcomponents such as "Valves" at this level.
>>>> Documentation at /docs/config/service.html
>>>> -->
>>>> <Service name="Catalina">
>>>>
>>>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>>>> <!--
>>>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>>>> maxThreads="150" minSpareThreads="4"/>
>>>> -->
>>>>
>>>>
>>>> <!-- A "Connector" represents an endpoint by which requests are received
>>>> and responses are returned. Documentation at :
>>>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>>>> Java AJP Connector: /docs/config/ajp.html
>>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>>> -->
>>>> <Connector port="8080" protocol="HTTP/1.1"
>>>> maxThreads="300" connectionTimeout="20000"
>>>> redirectPort="8443" />
>>>> <!-- A "Connector" using the shared thread pool-->
>>>> <!--
>>>> <Connector executor="tomcatThreadPool"
>>>> port="8080" protocol="HTTP/1.1"
>>>> connectionTimeout="20000"
>>>> redirectPort="8443" />
>>>> -->
>>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>>> This connector uses the NIO implementation that requires the JSSE
>>>> style configuration. When using the APR/native implementation, the
>>>> OpenSSL style configuration is required as described in the APR/native
>>>> documentation -->
>>>> <!--
>>>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>>>> clientAuth="false" sslProtocol="TLS" />
>>>> -->
>>>>
>>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>>>
>>>>
>>>> <!-- An Engine represents the entry point (within Catalina) that processes
>>>> every request. The Engine implementation for Tomcat stand alone
>>>> analyzes the HTTP headers included with the request, and passes them
>>>> on to the appropriate Host (virtual host).
>>>> Documentation at /docs/config/engine.html -->
>>>>
>>>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>>> -->
>>>> <Engine name="Catalina" defaultHost="localhost">
>>>>
>>>> <!--For clustering, please take a look at documentation at:
>>>> /docs/cluster-howto.html (simple how to)
>>>> /docs/config/cluster.html (reference documentation) -->
>>>> <!--
>>>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>>> -->
>>>>
>>>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>>>> via a brute-force attack -->
>>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>>>> resources under the key "UserDatabase". Any edits
>>>> that are performed against this UserDatabase are immediately
>>>> available for use by the Realm. -->
>>>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>>>> resourceName="UserDatabase"/>
>>>> </Realm>
>>>>
>>>> <Host name="localhost" appBase="webapps"
>>>> unpackWARs="true" autoDeploy="true">
>>>>
>>>> <!-- SingleSignOn valve, share authentication between web applications
>>>> Documentation at: /docs/config/valve.html -->
>>>> <!--
>>>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>>>> -->
>>>>
>>>> <!-- Access log processes all example.
>>>> Documentation at: /docs/config/valve.html
>>>> Note: The pattern used is equivalent to using pattern="common" -->
>>>>
>>>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>>>> prefix="localhost_access_log" suffix=".txt"
>>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>>
>>>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>>> </Host>
>>>> </Engine>
>>>> </Service>
>>>> </Server>
>>>>
>>>> -----Original Message-----
>>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>>> Sent: Friday, January 13, 2017 10:42 AM
>>>> To: users@tomcat.apache.org
>>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>>
>>>> On 13.01.2017 09:38, smith wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: smith [mailto:smith.hua@zoom.us]
>>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>>> To: 'users'
>>>>> Subject: tomcat 8080 thread not reduced
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>>>
>>>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>>
>>>>> When will the thread reduce?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Best regards
>>>>>
>>>>> Smith
>>>>>
>>>>>
>>>>
>>>> Hi.
>>>>
>>>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>>>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Busy one is process customer request, do not know what non-busy one is doing, always keep 120 for many days. I don't think 20s timeout will not cause so long connection
-smith
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Monday, January 16, 2017 8:33 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 16.01.2017 03:41, Smith Hua wrote:
>
> actually there is not much busy threads, less tahn 10,so i think this
> parameter may has nothing to do with this
It depends on what you call "busy". What are the busy ones doing ? and what are the non-busy ones doing ?
> --
> 从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00 发件人 André Warnier (tomcat) aw@ice-sa.com :
>
>> Hi.
>>
>> I can find nothing really wrong in your configuration below.
>> But, what happens if in this section :
>>
>> > <Connector port="8080" protocol="HTTP/1.1"
>> > maxThreads="300" connectionTimeout="20000"
>> > redirectPort="8443" />
>>
>> you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>>
>> Do you still see the number of threads remaining at the maximum ?
>>
>> See : http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
>> --> connectionTimeout
>> and the fact that it is also the default for
>> keepAliveTimeout
>>
>>
>> On 14.01.2017 07:30, smith wrote:
>>> The server.xml:
>>>
>>> <?xml version='1.0' encoding='utf-8'?>
>>> <!--
>>> Licensed to the Apache Software Foundation (ASF) under one or more
>>> contributor license agreements. See the NOTICE file distributed with
>>> this work for additional information regarding copyright ownership.
>>> The ASF licenses this file to You under the Apache License, Version 2.0
>>> (the "License"); you may not use this file except in compliance with
>>> the License. You may obtain a copy of the License at
>>>
>>> http://www.apache.org/licenses/LICENSE-2.0
>>>
>>> Unless required by applicable law or agreed to in writing, software
>>> distributed under the License is distributed on an "AS IS" BASIS,
>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>> See the License for the specific language governing permissions and
>>> limitations under the License.
>>> -->
>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>> define subcomponents such as "Valves" at this level.
>>> Documentation at /docs/config/server.html
>>> -->
>>> <Server port="8005" shutdown="SHUTDOWN">
>>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>>> <!-- Security listener. Documentation at /docs/config/listeners.html
>>> <Listener className="org.apache.catalina.security.SecurityListener" />
>>> -->
>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>>
>>> <!-- Global JNDI resources
>>> Documentation at /docs/jndi-resources-howto.html
>>> -->
>>> <GlobalNamingResources>
>>> <!-- Editable user database that can also be used by
>>> UserDatabaseRealm to authenticate users
>>> -->
>>> <Resource name="UserDatabase" auth="Container"
>>> type="org.apache.catalina.UserDatabase"
>>> description="User database that can be updated and saved"
>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>> pathname="conf/tomcat-users.xml" />
>>> </GlobalNamingResources>
>>>
>>> <!-- A "Service" is a collection of one or more "Connectors" that share
>>> a single "Container" Note: A "Service" is not itself a "Container",
>>> so you may not define subcomponents such as "Valves" at this level.
>>> Documentation at /docs/config/service.html
>>> -->
>>> <Service name="Catalina">
>>>
>>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>>> <!--
>>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>>> maxThreads="150" minSpareThreads="4"/>
>>> -->
>>>
>>>
>>> <!-- A "Connector" represents an endpoint by which requests are received
>>> and responses are returned. Documentation at :
>>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>>> Java AJP Connector: /docs/config/ajp.html
>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>> -->
>>> <Connector port="8080" protocol="HTTP/1.1"
>>> maxThreads="300" connectionTimeout="20000"
>>> redirectPort="8443" />
>>> <!-- A "Connector" using the shared thread pool-->
>>> <!--
>>> <Connector executor="tomcatThreadPool"
>>> port="8080" protocol="HTTP/1.1"
>>> connectionTimeout="20000"
>>> redirectPort="8443" />
>>> -->
>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>> This connector uses the NIO implementation that requires the JSSE
>>> style configuration. When using the APR/native implementation, the
>>> OpenSSL style configuration is required as described in the APR/native
>>> documentation -->
>>> <!--
>>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>>> clientAuth="false" sslProtocol="TLS" />
>>> -->
>>>
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>>
>>> <!-- An Engine represents the entry point (within Catalina) that processes
>>> every request. The Engine implementation for Tomcat stand alone
>>> analyzes the HTTP headers included with the request, and passes them
>>> on to the appropriate Host (virtual host).
>>> Documentation at /docs/config/engine.html -->
>>>
>>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>> -->
>>> <Engine name="Catalina" defaultHost="localhost">
>>>
>>> <!--For clustering, please take a look at documentation at:
>>> /docs/cluster-howto.html (simple how to)
>>> /docs/config/cluster.html (reference documentation) -->
>>> <!--
>>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>> -->
>>>
>>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>>> via a brute-force attack -->
>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>>> resources under the key "UserDatabase". Any edits
>>> that are performed against this UserDatabase are immediately
>>> available for use by the Realm. -->
>>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>>> resourceName="UserDatabase"/>
>>> </Realm>
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true">
>>>
>>> <!-- SingleSignOn valve, share authentication between web applications
>>> Documentation at: /docs/config/valve.html -->
>>> <!--
>>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>>> -->
>>>
>>> <!-- Access log processes all example.
>>> Documentation at: /docs/config/valve.html
>>> Note: The pattern used is equivalent to using pattern="common" -->
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>>> prefix="localhost_access_log" suffix=".txt"
>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>
>>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>> </Host>
>>> </Engine>
>>> </Service>
>>> </Server>
>>>
>>> -----Original Message-----
>>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Friday, January 13, 2017 10:42 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 13.01.2017 09:38, smith wrote:
>>>>
>>>>
>>>>
>>>>
>>>> From: smith [mailto:smith.hua@zoom.us]
>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>> To: 'users'
>>>> Subject: tomcat 8080 thread not reduced
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>>
>>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>
>>>> When will the thread reduce?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards
>>>>
>>>> Smith
>>>>
>>>>
>>>
>>> Hi.
>>>
>>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 16.01.2017 03:41, Smith Hua wrote:
>
> actually there is not much busy threads, less tahn 10,so i think this parameter may has nothing to do with this
It depends on what you call "busy". What are the busy ones doing ? and what are the
non-busy ones doing ?
> --
> \u4ecemyMail\u7684Android\u4e13\u7528app\u6240\u53d1\u9001 \u661f\u671f\u4e00, 16 \u4e00\u6708 2017, 03:01\u4e0a\u5348 +08:00 \u53d1\u4ef6\u4eba Andr� Warnier (tomcat) aw@ice-sa.com :
>
>> Hi.
>>
>> I can find nothing really wrong in your configuration below.
>> But, what happens if in this section :
>>
>> > <Connector port="8080" protocol="HTTP/1.1"
>> > maxThreads="300" connectionTimeout="20000"
>> > redirectPort="8443" />
>>
>> you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>>
>> Do you still see the number of threads remaining at the maximum ?
>>
>> See : http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
>> --> connectionTimeout
>> and the fact that it is also the default for
>> keepAliveTimeout
>>
>>
>> On 14.01.2017 07:30, smith wrote:
>>> The server.xml:
>>>
>>> <?xml version='1.0' encoding='utf-8'?>
>>> <!--
>>> Licensed to the Apache Software Foundation (ASF) under one or more
>>> contributor license agreements. See the NOTICE file distributed with
>>> this work for additional information regarding copyright ownership.
>>> The ASF licenses this file to You under the Apache License, Version 2.0
>>> (the "License"); you may not use this file except in compliance with
>>> the License. You may obtain a copy of the License at
>>>
>>> http://www.apache.org/licenses/LICENSE-2.0
>>>
>>> Unless required by applicable law or agreed to in writing, software
>>> distributed under the License is distributed on an "AS IS" BASIS,
>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>>> See the License for the specific language governing permissions and
>>> limitations under the License.
>>> -->
>>> <!-- Note: A "Server" is not itself a "Container", so you may not
>>> define subcomponents such as "Valves" at this level.
>>> Documentation at /docs/config/server.html
>>> -->
>>> <Server port="8005" shutdown="SHUTDOWN">
>>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>>> <!-- Security listener. Documentation at /docs/config/listeners.html
>>> <Listener className="org.apache.catalina.security.SecurityListener" />
>>> -->
>>> <!--APR library loader. Documentation at /docs/apr.html -->
>>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>>
>>> <!-- Global JNDI resources
>>> Documentation at /docs/jndi-resources-howto.html
>>> -->
>>> <GlobalNamingResources>
>>> <!-- Editable user database that can also be used by
>>> UserDatabaseRealm to authenticate users
>>> -->
>>> <Resource name="UserDatabase" auth="Container"
>>> type="org.apache.catalina.UserDatabase"
>>> description="User database that can be updated and saved"
>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>>> pathname="conf/tomcat-users.xml" />
>>> </GlobalNamingResources>
>>>
>>> <!-- A "Service" is a collection of one or more "Connectors" that share
>>> a single "Container" Note: A "Service" is not itself a "Container",
>>> so you may not define subcomponents such as "Valves" at this level.
>>> Documentation at /docs/config/service.html
>>> -->
>>> <Service name="Catalina">
>>>
>>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>>> <!--
>>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>>> maxThreads="150" minSpareThreads="4"/>
>>> -->
>>>
>>>
>>> <!-- A "Connector" represents an endpoint by which requests are received
>>> and responses are returned. Documentation at :
>>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>>> Java AJP Connector: /docs/config/ajp.html
>>> APR (HTTP/AJP) Connector: /docs/apr.html
>>> Define a non-SSL HTTP/1.1 Connector on port 8080
>>> -->
>>> <Connector port="8080" protocol="HTTP/1.1"
>>> maxThreads="300" connectionTimeout="20000"
>>> redirectPort="8443" />
>>> <!-- A "Connector" using the shared thread pool-->
>>> <!--
>>> <Connector executor="tomcatThreadPool"
>>> port="8080" protocol="HTTP/1.1"
>>> connectionTimeout="20000"
>>> redirectPort="8443" />
>>> -->
>>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>>> This connector uses the NIO implementation that requires the JSSE
>>> style configuration. When using the APR/native implementation, the
>>> OpenSSL style configuration is required as described in the APR/native
>>> documentation -->
>>> <!--
>>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>>> clientAuth="false" sslProtocol="TLS" />
>>> -->
>>>
>>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>>
>>>
>>> <!-- An Engine represents the entry point (within Catalina) that processes
>>> every request. The Engine implementation for Tomcat stand alone
>>> analyzes the HTTP headers included with the request, and passes them
>>> on to the appropriate Host (virtual host).
>>> Documentation at /docs/config/engine.html -->
>>>
>>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>>> -->
>>> <Engine name="Catalina" defaultHost="localhost">
>>>
>>> <!--For clustering, please take a look at documentation at:
>>> /docs/cluster-howto.html (simple how to)
>>> /docs/config/cluster.html (reference documentation) -->
>>> <!--
>>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>>> -->
>>>
>>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>>> via a brute-force attack -->
>>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>>> resources under the key "UserDatabase". Any edits
>>> that are performed against this UserDatabase are immediately
>>> available for use by the Realm. -->
>>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>>> resourceName="UserDatabase"/>
>>> </Realm>
>>>
>>> <Host name="localhost" appBase="webapps"
>>> unpackWARs="true" autoDeploy="true">
>>>
>>> <!-- SingleSignOn valve, share authentication between web applications
>>> Documentation at: /docs/config/valve.html -->
>>> <!--
>>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>>> -->
>>>
>>> <!-- Access log processes all example.
>>> Documentation at: /docs/config/valve.html
>>> Note: The pattern used is equivalent to using pattern="common" -->
>>>
>>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>>> prefix="localhost_access_log" suffix=".txt"
>>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>>
>>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>>> </Host>
>>> </Engine>
>>> </Service>
>>> </Server>
>>>
>>> -----Original Message-----
>>> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
>>> Sent: Friday, January 13, 2017 10:42 AM
>>> To: users@tomcat.apache.org
>>> Subject: Re: FW: tomcat 8080 thread not reduced
>>>
>>> On 13.01.2017 09:38, smith wrote:
>>>>
>>>>
>>>>
>>>>
>>>> From: smith [mailto:smith.hua@zoom.us]
>>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>>> To: 'users'
>>>> Subject: tomcat 8080 thread not reduced
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>>
>>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>>
>>>> When will the thread reduce?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards
>>>>
>>>> Smith
>>>>
>>>>
>>>
>>> Hi.
>>>
>>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re[2]: FW: tomcat 8080 thread not reduced
Posted by Smith Hua <sm...@zoom.us>.
actually there is not much busy threads, less tahn 10,so i think this parameter may has nothing to do with this
--
从myMail的Android专用app所发送 星期一, 16 一月 2017, 03:01上午 +08:00 发件人 André Warnier (tomcat) aw@ice-sa.com :
>Hi.
>
>I can find nothing really wrong in your configuration below.
>But, what happens if in this section :
>
> > <Connector port="8080" protocol="HTTP/1.1"
> > maxThreads="300" connectionTimeout="20000"
> > redirectPort="8443" />
>
>you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
>
>Do you still see the number of threads remaining at the maximum ?
>
>See : http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
>--> connectionTimeout
>and the fact that it is also the default for
>keepAliveTimeout
>
>
>On 14.01.2017 07:30, smith wrote:
>> The server.xml:
>>
>> <?xml version='1.0' encoding='utf-8'?>
>> <!--
>> Licensed to the Apache Software Foundation (ASF) under one or more
>> contributor license agreements. See the NOTICE file distributed with
>> this work for additional information regarding copyright ownership.
>> The ASF licenses this file to You under the Apache License, Version 2.0
>> (the "License"); you may not use this file except in compliance with
>> the License. You may obtain a copy of the License at
>>
>> http://www.apache.org/licenses/LICENSE-2.0
>>
>> Unless required by applicable law or agreed to in writing, software
>> distributed under the License is distributed on an "AS IS" BASIS,
>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>> See the License for the specific language governing permissions and
>> limitations under the License.
>> -->
>> <!-- Note: A "Server" is not itself a "Container", so you may not
>> define subcomponents such as "Valves" at this level.
>> Documentation at /docs/config/server.html
>> -->
>> <Server port="8005" shutdown="SHUTDOWN">
>> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
>> <!-- Security listener. Documentation at /docs/config/listeners.html
>> <Listener className="org.apache.catalina.security.SecurityListener" />
>> -->
>> <!--APR library loader. Documentation at /docs/apr.html -->
>> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
>> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>>
>> <!-- Global JNDI resources
>> Documentation at /docs/jndi-resources-howto.html
>> -->
>> <GlobalNamingResources>
>> <!-- Editable user database that can also be used by
>> UserDatabaseRealm to authenticate users
>> -->
>> <Resource name="UserDatabase" auth="Container"
>> type="org.apache.catalina.UserDatabase"
>> description="User database that can be updated and saved"
>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>> pathname="conf/tomcat-users.xml" />
>> </GlobalNamingResources>
>>
>> <!-- A "Service" is a collection of one or more "Connectors" that share
>> a single "Container" Note: A "Service" is not itself a "Container",
>> so you may not define subcomponents such as "Valves" at this level.
>> Documentation at /docs/config/service.html
>> -->
>> <Service name="Catalina">
>>
>> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
>> <!--
>> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
>> maxThreads="150" minSpareThreads="4"/>
>> -->
>>
>>
>> <!-- A "Connector" represents an endpoint by which requests are received
>> and responses are returned. Documentation at :
>> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
>> Java AJP Connector: /docs/config/ajp.html
>> APR (HTTP/AJP) Connector: /docs/apr.html
>> Define a non-SSL HTTP/1.1 Connector on port 8080
>> -->
>> <Connector port="8080" protocol="HTTP/1.1"
>> maxThreads="300" connectionTimeout="20000"
>> redirectPort="8443" />
>> <!-- A "Connector" using the shared thread pool-->
>> <!--
>> <Connector executor="tomcatThreadPool"
>> port="8080" protocol="HTTP/1.1"
>> connectionTimeout="20000"
>> redirectPort="8443" />
>> -->
>> <!-- Define a SSL HTTP/1.1 Connector on port 8443
>> This connector uses the NIO implementation that requires the JSSE
>> style configuration. When using the APR/native implementation, the
>> OpenSSL style configuration is required as described in the APR/native
>> documentation -->
>> <!--
>> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
>> clientAuth="false" sslProtocol="TLS" />
>> -->
>>
>> <!-- Define an AJP 1.3 Connector on port 8009 -->
>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>>
>>
>> <!-- An Engine represents the entry point (within Catalina) that processes
>> every request. The Engine implementation for Tomcat stand alone
>> analyzes the HTTP headers included with the request, and passes them
>> on to the appropriate Host (virtual host).
>> Documentation at /docs/config/engine.html -->
>>
>> <!-- You should set jvmRoute to support load-balancing via AJP ie :
>> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
>> -->
>> <Engine name="Catalina" defaultHost="localhost">
>>
>> <!--For clustering, please take a look at documentation at:
>> /docs/cluster-howto.html (simple how to)
>> /docs/config/cluster.html (reference documentation) -->
>> <!--
>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
>> -->
>>
>> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
>> via a brute-force attack -->
>> <Realm className="org.apache.catalina.realm.LockOutRealm">
>> <!-- This Realm uses the UserDatabase configured in the global JNDI
>> resources under the key "UserDatabase". Any edits
>> that are performed against this UserDatabase are immediately
>> available for use by the Realm. -->
>> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
>> resourceName="UserDatabase"/>
>> </Realm>
>>
>> <Host name="localhost" appBase="webapps"
>> unpackWARs="true" autoDeploy="true">
>>
>> <!-- SingleSignOn valve, share authentication between web applications
>> Documentation at: /docs/config/valve.html -->
>> <!--
>> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
>> -->
>>
>> <!-- Access log processes all example.
>> Documentation at: /docs/config/valve.html
>> Note: The pattern used is equivalent to using pattern="common" -->
>>
>> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
>> prefix="localhost_access_log" suffix=".txt"
>> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>>
>> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
>> </Host>
>> </Engine>
>> </Service>
>> </Server>
>>
>> -----Original Message-----
>> From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
>> Sent: Friday, January 13, 2017 10:42 AM
>> To: users@tomcat.apache.org
>> Subject: Re: FW: tomcat 8080 thread not reduced
>>
>> On 13.01.2017 09:38, smith wrote:
>>>
>>>
>>>
>>>
>>> From: smith [mailto:smith.hua@zoom.us]
>>> Sent: Tuesday, January 10, 2017 9:57 AM
>>> To: 'users'
>>> Subject: tomcat 8080 thread not reduced
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>>
>>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>>
>>> When will the thread reduce?
>>>
>>>
>>>
>>>
>>>
>>> Best regards
>>>
>>> Smith
>>>
>>>
>>
>> Hi.
>>
>> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
>> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 22.01.2017 07:37, smith wrote:
> Hi, Chris
>
> We don't just care about free, we care about active too. We know how many free also means how many are active
>
> We are using HTTP
>
> Let's me take one example from manager status: (this is the manager output)
> Max threads: 200 Current thread count: 23 Current thread busy: 1 Keeped alive sockets count: 1
>
> Current thread count: 23 I want to know if these 23 threads are free to use, or they are active, cannot accept new connection? Here are Keeped alive sockets count, it's only 1, is this 1 for the busy thread or a thread in 23?
>
Max threads : 200
-----------------
That is the maximum number of threads that tomcat will ever allocate, no matter how busy
your server becomes.
Current thread count : 23
-------------------------
That is how many threads have been allocated and exist so far. If you do not use an
Executor, then this number will never go down again (but it may go up). Included in this
count are :
a) the threads currently busy processing a request
b) the threads which may not be actually executing a request, but are blocked on a
keep-alive connection, waiting if there is another request coming on that same client
connection. These threads are not available for a new client connection, but they are
available to process a new request on the same client connection for which they have
already processed at least one request recently.
c) the threads which are not doing anything, and which are available to process new
connections and new requests on such new connections
Current thread busy: 1
----------------------
This the thread (a) above. It is in fact the thread which is processing your "manager"
request.
Keeped alive sockets count: 1
-----------------------------
This a thread in status (b) above. It is not the same thread as (a).
It is not available for a new client connection, because it is still waiting on its
current client connection. But it is available for a new request *on the same connection*,
for the remainder of its keep-alive timeout.
If there is no no new request on that same connection, then when the keep-alive timeout
expires, it will close the connection and go to status (c).
If there is a new request on the same connection, it will go to status (a) and process
that request; and when it is finished, the timeout will be reset to the keep-alive timeout
and it will return to status (b).
So you have :
total threads : 23
- busy threads : -1
- keepalive threads : -1
====================
= available for new connections : 21
From time to time, tomcat will look at how many threads are in status (c) above. It if
it not at least minSpareThreads, additional threads will be created until there are
minSpareThreads in status (c), with a maximum of maxThreads threads in total.
If you server was receiving now suddenly 50 new requests from 50 new clients at the same
time, then :
- 21 requests would be processed by the 21 threads currently in status (c) (which will go
to status (a)
- tomcat would create 29 new threads immediately, to process the other 29 requests. These
threads would start in status (a), and when their request is finished, they would go to
status (b) for the keepAlive timeout
- possibly, the background watchdog would run at that same moment and see that there are
no longer minSpareThreads available in status (c). It would then create new threads in
status (c), to bring this back to minSpareThreads.
At the end of this, you would now have (possibly) 60 threads in total, forever, which will
slowly go back all to status (c) if no more requests are coming.
If you want another behaviour, then you should use an Executor.
> -Smith
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Friday, January 20, 2017 10:29 PM
> To: Tomcat Users List
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Smith,
>
> On 1/19/17 9:59 PM, smith wrote:
>>> "busy" is the same as "active".
>>
>> When not use <Executor>, our busy thread always keep under 10 while
>> the currentThreadCount keeps high (these are get from tomcat manager),
>> So we really don't know how many threads are truly free.
>
> Why do you care how many are free? Isn't it more important to know how many are active? For example, I run my app servers with maxThreads="150" for the most part. Then, I have Nagios notify me if the "active count" goes above 135 (that's 90% of my maxThreads).
>
> Nagios, like many monitoring systems, won't scream the first time it sees something. Instead, it will check again a few times before complaining. That means that as long as I don't see any significant duration where the active thread count exceeds 135, I don't get any alarms going off.
>
> And I don't care how many "free" threads I have. I've decided that I want "150 and NO MORE". Nothing else matters except the active count.
> I don't happen to allow the thread pool to re-size downward (fewer threads), but if I did, I wouldn't have to change my monitoring at all. What? The active count is 10 and the total pool size is 20? I don't care. Wake me up when the active thread count stays high for a while, indicating to me that we are getting hammered.
>
>> How many are in keepAlivedStatus
>
> Use NIO and forget about it.
>
> Besides, you are using *AJP*. Every thread is *always* in a keepalive state. So keepalive == idle as far as Tomcat is concerned.
>
> If you were using HTTP, then keepalive would be an issue (and NIO would be the answer), but you aren't, so it's not.
>
> - -chris
>
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Thursday, January 19,
>> 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 thread
>> not reduced
>>
>> 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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>
>>
>>
>>>>> -------------------------------------------------------------------
> - -
>>
>>>>>
> - -
>>
>>>>>
>>>>>
>>>>>
>>
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>
>>
>>>> --------------------------------------------------------------------
> - -
>>
>>>>
>>>>
>>>>
>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>>> --------------------------------------------------------------------
> - -
>>
>>>>
>>>>
>>>>
>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYgo82AAoJEBzwKT+lPKRYcMYQAJYCFBKsDAfUlcTOagqMQARA
> JEQudRYLRUt4LDGiKiCz9q3bZImxuH63jFj5biRMi88jBa3uCF/mQciodbxVrldL
> yAVchYCSFay0kwj8YLCLJ8zsuVziQKob2/X06QERzumpCVUOXoUM9cswYA0om3LS
> LNGamV4xeb5l60uoiBYlxg7K+7ivbwDpN67+hu8hCEdxSyYal8s3XRihxHPAGdS4
> LIw0cxigWmg+zW+DKs8k4t6PqdVOahSrIlgZ8pxSKjqoji/wP3zKQSHExDMJYJMf
> GxRzsdHRKRozmIo9oRxRnieRESV7laNwndgmNb2/LriVgHE2wTFf1ylMsl7ho9kz
> Zz13tuCPt822dIqfoKnx1Re+tms0nyUzg7ihto53ZgD0GrdxeJFzOG4wFKQJdvLW
> hoGoBifK48FW8Q0ryudmDPQH0slvw0QAH3pG5qJOu9+UZ4/GuCFECv3pwVOCdhH6
> kgj3H32ZsakC6A9JkOwvVb/4Tyg+UzhjaEY6UZP1hPmDxpwICyXjqgqUWuB3WI5L
> QxF6ofi/B4+DpmE4uh6I3LohIW+2Q4/5l/3D9t4CqysLHyJVenYd04tL6dSwCNOd
> upuZ9FDJqg0bamKfE5c9Pjvka7J00GmHkgCcSLYdS8NMwrb80dHcsH3CwWU/fHyO
> Jq6xTAUf5k8iAowhYnkh
> =YRYR
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Smith,
On 1/22/17 1:37 AM, smith wrote:
> We don't just care about free, we care about active too. We know
> how many free also means how many are active
If you are using a dynamically-sized pool, then you don't really know
how many you have free if you sample active, or how many you have
active if you sample free ones. You have to collect both stats in
order to know whether or not there is a problem.
Of course, the size of the pool can chance between samples of
free/active so you are never getting a perfect picture.
> We are using HTTP
That wasn't clear from any of your previous posts. In that case
keepalive could be an issue. The solution is to use a NIO connector.
> Let's me take one example from manager status: (this is the
> manager output) Max threads: 200 Current thread count: 23 Current
> thread busy: 1 Keeped alive sockets count: 1
>
> Current thread count: 23 I want to know if these 23 threads are
> free to use, or they are active, cannot accept new connection? Here
> are Keeped alive sockets count, it's only 1, is this 1 for the
> busy thread or a thread in 23?
The current thread count tells you how many java.lang.Thread objects
are being managed by the thread pool. It says nothing about their
state. The 200 is obviously the limit of threads that *would* be
managed by the pool.
I would have to read the code to find out if a keep-alive connection
counts as "busy" or not. But you don't want keepAlive connections to
hold-up a thread, so you should use an NIO connector.
Since you are using Tomcat 8 (albeit an old version) without
specifying a certain type of connector, you are already getting either
the NIO connector or the APR connector (if the native library is
available). Neither of those connectors will hold-up a thread for a
keepalive connection.
I suspect that "busy:1, keepalive:1" for you means that there is
currently 1 thread actually processing a request, and you have 22
threads idle. The keepalive:1 means that one socket connection is in
the keepalive state, but it's not consuming a thread.
- -chris
> -----Original Message----- From: Christopher Schultz
> [mailto:chris@christopherschultz.net] Sent: Friday, January 20,
> 2017 10:29 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080
> thread not reduced
>
> Smith,
>
> On 1/19/17 9:59 PM, smith wrote:
>>> "busy" is the same as "active".
>
>> When not use <Executor>, our busy thread always keep under 10
>> while the currentThreadCount keeps high (these are get from
>> tomcat manager), So we really don't know how many threads are
>> truly free.
>
> Why do you care how many are free? Isn't it more important to know
> how many are active? For example, I run my app servers with
> maxThreads="150" for the most part. Then, I have Nagios notify me
> if the "active count" goes above 135 (that's 90% of my
> maxThreads).
>
> Nagios, like many monitoring systems, won't scream the first time
> it sees something. Instead, it will check again a few times before
> complaining. That means that as long as I don't see any
> significant duration where the active thread count exceeds 135, I
> don't get any alarms going off.
>
> And I don't care how many "free" threads I have. I've decided that
> I want "150 and NO MORE". Nothing else matters except the active
> count. I don't happen to allow the thread pool to re-size downward
> (fewer threads), but if I did, I wouldn't have to change my
> monitoring at all. What? The active count is 10 and the total pool
> size is 20? I don't care. Wake me up when the active thread count
> stays high for a while, indicating to me that we are getting
> hammered.
>
>> How many are in keepAlivedStatus
>
> Use NIO and forget about it.
>
> Besides, you are using *AJP*. Every thread is *always* in a
> keepalive state. So keepalive == idle as far as Tomcat is
> concerned.
>
> If you were using HTTP, then keepalive would be an issue (and NIO
> would be the answer), but you aren't, so it's not.
>
> -chris
>
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Thursday, January 19,
>> 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080
>> thread not reduced
>
>> 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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>
>
>
>>>>> ------------------------------------------------------------------
- -
>
>>>>>
>>>>>
- -
>
>>>>>
> -
>
>>>>>
>>>>>
>>>>>
>
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>
>
>>>> -------------------------------------------------------------------
- -
>
>>>>
>>>>
- -
>
>>>>
>>>>
>>>>
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>
>>>> -------------------------------------------------------------------
- -
>
>>>>
>>>>
- -
>
>>>>
>>>>
>>>>
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYhiVJAAoJEBzwKT+lPKRYLXMP/iVhfgmu6TkURPoYpbzJirOb
km4WRQFtGazUtLEM0hPS8KGc3sa62YJJEyflbvi0PL/lX0BK1FE6h8Pb300Ik+pY
Jfdc5QeAtChjjEDGiKIRz+YBwRidNqy4GGlq7gPzsNMDSc1GTl6vCnR//p3E9ey1
c8a6A1oYUeVtFho21CwDG8dtUwL5ycNgBKqLuPgfBckNeK6ldmX2KR1Ctjnck1yQ
5obgagWaB89FyDarAIIdjQEOSai2o0Ui/c7GbzjBTu5SkEgG9gT9U9RlC0H/J4vD
zXtlKYR0QKSAZ5pnh3LFDYQdkNJ7MAIbAYXxFVofFi+bG1gOXQ8ex3/3kzJDrDl6
e9kKKI4Yn/h1Qh7pvrXEzlXSJh6fhr4rG1uGqQdSNIq+29a3MKxpIWDUG4ybdqOZ
JaqRS7Hif2ARFTn8eh+NoOTZocIVdoFq9qv4jc/RT8O/uz89DfYvZqQmsXwHwEgo
HrLDDiykwMo+2zI5Zo9Okyka/vMabBpUk560QZ9Raej6PaFJHXMg2L2tQiSk27hH
01to3eYLqCgYNFP4XCIJ1kec/XzhbbkkvE87N+chSOMeFDEH2lKonT7nZds8XLA+
79gWfLDIhTagZOmzH5Y+Bd/tWu7iWJyFRzWOf6v6YZMdPHvD5egIBBbu0E3XUJBB
veJFv1GTsAVxma5V4lrP
=Zmkp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Hi, Chris
We don't just care about free, we care about active too. We know how many free also means how many are active
We are using HTTP
Let's me take one example from manager status: (this is the manager output)
Max threads: 200 Current thread count: 23 Current thread busy: 1 Keeped alive sockets count: 1
Current thread count: 23 I want to know if these 23 threads are free to use, or they are active, cannot accept new connection? Here are Keeped alive sockets count, it's only 1, is this 1 for the busy thread or a thread in 23?
-Smith
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Friday, January 20, 2017 10:29 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Smith,
On 1/19/17 9:59 PM, smith wrote:
>> "busy" is the same as "active".
>
> When not use <Executor>, our busy thread always keep under 10 while
> the currentThreadCount keeps high (these are get from tomcat manager),
> So we really don't know how many threads are truly free.
Why do you care how many are free? Isn't it more important to know how many are active? For example, I run my app servers with maxThreads="150" for the most part. Then, I have Nagios notify me if the "active count" goes above 135 (that's 90% of my maxThreads).
Nagios, like many monitoring systems, won't scream the first time it sees something. Instead, it will check again a few times before complaining. That means that as long as I don't see any significant duration where the active thread count exceeds 135, I don't get any alarms going off.
And I don't care how many "free" threads I have. I've decided that I want "150 and NO MORE". Nothing else matters except the active count.
I don't happen to allow the thread pool to re-size downward (fewer threads), but if I did, I wouldn't have to change my monitoring at all. What? The active count is 10 and the total pool size is 20? I don't care. Wake me up when the active thread count stays high for a while, indicating to me that we are getting hammered.
> How many are in keepAlivedStatus
Use NIO and forget about it.
Besides, you are using *AJP*. Every thread is *always* in a keepalive state. So keepalive == idle as far as Tomcat is concerned.
If you were using HTTP, then keepalive would be an issue (and NIO would be the answer), but you aren't, so it's not.
- -chris
> -----Original Message----- From: Christopher Schultz
> [mailto:chris@christopherschultz.net] Sent: Thursday, January 19,
> 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080 thread
> not reduced
>
> 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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>
>>>> -------------------------------------------------------------------
- -
>
>>>>
- -
>
>>>>
>>>>
>>>>
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>> ---------------------------------------------------------------------
>
>>
>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYgo82AAoJEBzwKT+lPKRYcMYQAJYCFBKsDAfUlcTOagqMQARA
JEQudRYLRUt4LDGiKiCz9q3bZImxuH63jFj5biRMi88jBa3uCF/mQciodbxVrldL
yAVchYCSFay0kwj8YLCLJ8zsuVziQKob2/X06QERzumpCVUOXoUM9cswYA0om3LS
LNGamV4xeb5l60uoiBYlxg7K+7ivbwDpN67+hu8hCEdxSyYal8s3XRihxHPAGdS4
LIw0cxigWmg+zW+DKs8k4t6PqdVOahSrIlgZ8pxSKjqoji/wP3zKQSHExDMJYJMf
GxRzsdHRKRozmIo9oRxRnieRESV7laNwndgmNb2/LriVgHE2wTFf1ylMsl7ho9kz
Zz13tuCPt822dIqfoKnx1Re+tms0nyUzg7ihto53ZgD0GrdxeJFzOG4wFKQJdvLW
hoGoBifK48FW8Q0ryudmDPQH0slvw0QAH3pG5qJOu9+UZ4/GuCFECv3pwVOCdhH6
kgj3H32ZsakC6A9JkOwvVb/4Tyg+UzhjaEY6UZP1hPmDxpwICyXjqgqUWuB3WI5L
QxF6ofi/B4+DpmE4uh6I3LohIW+2Q4/5l/3D9t4CqysLHyJVenYd04tL6dSwCNOd
upuZ9FDJqg0bamKfE5c9Pjvka7J00GmHkgCcSLYdS8NMwrb80dHcsH3CwWU/fHyO
Jq6xTAUf5k8iAowhYnkh
=YRYR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Smith,
On 1/19/17 9:59 PM, smith wrote:
>> "busy" is the same as "active".
>
> When not use <Executor>, our busy thread always keep under 10
> while the currentThreadCount keeps high (these are get from tomcat
> manager), So we really don't know how many threads are truly free.
Why do you care how many are free? Isn't it more important to know how
many are active? For example, I run my app servers with
maxThreads="150" for the most part. Then, I have Nagios notify me if
the "active count" goes above 135 (that's 90% of my maxThreads).
Nagios, like many monitoring systems, won't scream the first time it
sees something. Instead, it will check again a few times before
complaining. That means that as long as I don't see any significant
duration where the active thread count exceeds 135, I don't get any
alarms going off.
And I don't care how many "free" threads I have. I've decided that I
want "150 and NO MORE". Nothing else matters except the active count.
I don't happen to allow the thread pool to re-size downward (fewer
threads), but if I did, I wouldn't have to change my monitoring at
all. What? The active count is 10 and the total pool size is 20? I
don't care. Wake me up when the active thread count stays high for a
while, indicating to me that we are getting hammered.
> How many are in keepAlivedStatus
Use NIO and forget about it.
Besides, you are using *AJP*. Every thread is *always* in a keepalive
state. So keepalive == idle as far as Tomcat is concerned.
If you were using HTTP, then keepalive would be an issue (and NIO
would be the answer), but you aren't, so it's not.
- -chris
> -----Original Message----- From: Christopher Schultz
> [mailto:chris@christopherschultz.net] Sent: Thursday, January 19,
> 2017 4:38 PM To: Tomcat Users List Subject: Re: FW: tomcat 8080
> thread not reduced
>
> 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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>
>>>> -------------------------------------------------------------------
- -
>
>>>>
- -
>
>>>>
>>>>
>>>>
>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>> ---------------------------------------------------------------------
>
>>
>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYgo82AAoJEBzwKT+lPKRYcMYQAJYCFBKsDAfUlcTOagqMQARA
JEQudRYLRUt4LDGiKiCz9q3bZImxuH63jFj5biRMi88jBa3uCF/mQciodbxVrldL
yAVchYCSFay0kwj8YLCLJ8zsuVziQKob2/X06QERzumpCVUOXoUM9cswYA0om3LS
LNGamV4xeb5l60uoiBYlxg7K+7ivbwDpN67+hu8hCEdxSyYal8s3XRihxHPAGdS4
LIw0cxigWmg+zW+DKs8k4t6PqdVOahSrIlgZ8pxSKjqoji/wP3zKQSHExDMJYJMf
GxRzsdHRKRozmIo9oRxRnieRESV7laNwndgmNb2/LriVgHE2wTFf1ylMsl7ho9kz
Zz13tuCPt822dIqfoKnx1Re+tms0nyUzg7ihto53ZgD0GrdxeJFzOG4wFKQJdvLW
hoGoBifK48FW8Q0ryudmDPQH0slvw0QAH3pG5qJOu9+UZ4/GuCFECv3pwVOCdhH6
kgj3H32ZsakC6A9JkOwvVb/4Tyg+UzhjaEY6UZP1hPmDxpwICyXjqgqUWuB3WI5L
QxF6ofi/B4+DpmE4uh6I3LohIW+2Q4/5l/3D9t4CqysLHyJVenYd04tL6dSwCNOd
upuZ9FDJqg0bamKfE5c9Pjvka7J00GmHkgCcSLYdS8NMwrb80dHcsH3CwWU/fHyO
Jq6xTAUf5k8iAowhYnkh
=YRYR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 20.01.2017 03:59, smith wrote:
> Hi, chris:
>
>> "busy" is the same as "active".
> When not use <Executor>, our busy thread always keep under 10 while the currentThreadCount keeps high (these are get from tomcat manager), So we really don't know how many threads are truly free. How many are in keepAlivedStatus
>
That may be my fault, in my contributions earlier.
I believe that it is reasonable to assume that "busy" also counts the threads which are
currently "in keepAlive" status. That is because these threads are not "free" to handle
new requests yet from other clients than the one which "owns" the connection on which they
are in keepAlive.
But I do not know the code, so someone else may want to confirm/correct this.
Anyway, you do have a simple way to verify this : reduce the keepAlive to 5 seconds,
instead of 20, and see how it impacts the counts that you are seeing.
If keepAlive counts as "busy", then you should see less "busy" threads on average.
If keepAlive does not count as busy, then you will see no difference.
One more proviso : the above is for the case where clients connect to tomcat directly,
without a front-end, which may itself create a pool of permanent connections to tomcat.
(Chris already mentioned that).
If there is such a front-end, and it does something like "pings" on each connection to the
tomcat back-end connections all the time, then you would have, on the tomcat side, an
alsmost constant number of threads in keepAlive wait status.
All in all, considering your ultimate purpose (to determine when your tomcat is getting
close to the limit of what it can handle, and decide if you need more tomcats or not), I
believe that your current focus on the number of tomcat threads active or not, may not be
the best diagnostic tool.
Maybe a better tool would be to look at the number of connections which are waiting to be
accepted. This should always be 0, or small. If it starts growing, then that is a clear
signal that tomcat is getting saturated. (This is related to the "acceptCount" attribute
of the Connectors).
Another tool may be to look at how long it takes tomcat to respond to requests (or at
least some specific types of requests). You can probably set a baseline, when you know
that tomcat is really not heavily loaded (maybe on your development system e.g.). And
then, when you see this response time increasing seriously, is when you should start
analysing why. (*)
This kind of approach would have the advantage of focusing on what really matters in the
end : the ability of your server (as a whole : hardware, OS, tomcat and applications
included) to handle a given number of requests within a given time interval, with /your/
mix of clients and applications.
(*) because the reason may be for example that you need more memory, not more threads.
>
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: Thursday, January 19, 2017 4:38 PM
> To: Tomcat Users List
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> -----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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>>> --------------------------------------------------------------------
> - -
>>
>>>>
>>>>
>>>>
>>
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>> ---------------------------------------------------------------------
>>
>>>
>>>
>>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Hi, chris:
>"busy" is the same as "active".
When not use <Executor>, our busy thread always keep under 10 while the currentThreadCount keeps high (these are get from tomcat manager), So we really don't know how many threads are truly free. How many are in keepAlivedStatus
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Thursday, January 19, 2017 4:38 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced
-----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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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:chris@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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>>> --------------------------------------------------------------------
- -
>
>>>
>>>
>>>
>
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Hi, Christopher
I don't care if the threads will be reduced, I just want to know why. 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.
Since not use the <Executor>, the busy thread account also cannot tell us the correct active threads count. In another email thread, you said if use <Executor>, it will tell us the right active thread count not just busy count, right?
-smith
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Wednesday, January 18, 2017 3:28 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYf4mVAAoJEBzwKT+lPKRYE1cQALnUh2se9iXDJB3r/1TiHfiy
RCEnqgjeYKaVyO0wBvG5PqyXGwedsh2i2TzuUW5zHXEi5qZhr91oZ/sEG8yOpdfv
zOb9ZeFpWJpkVuj/pa2kjszEs+gpUhth4+45ou7N9WAAkDsl4oWpHzC2aEWbNByf
u9gkt8yq5ZSccFP7/Xb7GhcjIKYpK+qK/1/U+vD9eC6sFuzpewC7+aZ1FwpQ7/6L
DlbqGRM3Uj0Yvft6YNfrmN5SY8VY4shv0f/b83tmaH8Bz2bgGhhqddAm/vSpDu44
67YU55m36NL9hTbiS4E/CnLCnZxsY7+RtR4Xz2g51KN7+OoKZIgQN7XzHYhQbTZS
NPZG1ejkE6s0R8oIjYHAO8cucSGshD7de42mdq6wrrxDrSodm29zUWS8TEgOkUBp
kuX7MzpmZt0s5YjSjwMLWXpWlmrVvbxawGNgZCFmz/At9FPt+BboymzsWQSEA+wQ
QgJHjXzp5iSskYxYdIPFCb+nhAk0AAqWG4NQs0KMRsGTqnwYYnCVT/YF2Se2kTpv
eUqlwI2rjPXiW2tKuDm+ZMENu6EbySSyngq7Ad0paIq4qXXp0QcGCN9SWSRgt6/g
YePmBR37SLKOrrkfWPFS/NRLEZg/pWhEcKVMuCDJSF/kGOca4AytQsJiZ66k0ecM
Jklop2vxVLIm1rEdO/m2
=ks8D
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:chris@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:chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>> ---------------------------------------------------------------------
>
>>
>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYf4mVAAoJEBzwKT+lPKRYE1cQALnUh2se9iXDJB3r/1TiHfiy
RCEnqgjeYKaVyO0wBvG5PqyXGwedsh2i2TzuUW5zHXEi5qZhr91oZ/sEG8yOpdfv
zOb9ZeFpWJpkVuj/pa2kjszEs+gpUhth4+45ou7N9WAAkDsl4oWpHzC2aEWbNByf
u9gkt8yq5ZSccFP7/Xb7GhcjIKYpK+qK/1/U+vD9eC6sFuzpewC7+aZ1FwpQ7/6L
DlbqGRM3Uj0Yvft6YNfrmN5SY8VY4shv0f/b83tmaH8Bz2bgGhhqddAm/vSpDu44
67YU55m36NL9hTbiS4E/CnLCnZxsY7+RtR4Xz2g51KN7+OoKZIgQN7XzHYhQbTZS
NPZG1ejkE6s0R8oIjYHAO8cucSGshD7de42mdq6wrrxDrSodm29zUWS8TEgOkUBp
kuX7MzpmZt0s5YjSjwMLWXpWlmrVvbxawGNgZCFmz/At9FPt+BboymzsWQSEA+wQ
QgJHjXzp5iSskYxYdIPFCb+nhAk0AAqWG4NQs0KMRsGTqnwYYnCVT/YF2Se2kTpv
eUqlwI2rjPXiW2tKuDm+ZMENu6EbySSyngq7Ad0paIq4qXXp0QcGCN9SWSRgt6/g
YePmBR37SLKOrrkfWPFS/NRLEZg/pWhEcKVMuCDJSF/kGOca4AytQsJiZ66k0ecM
Jklop2vxVLIm1rEdO/m2
=ks8D
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Thanks chris
So the tomcat default executor will not reduce the thread count until it reach to the max configuration? Will it reduce when it reach to max?
And why the default not reduce the thread?
-Smith
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Tuesday, January 17, 2017 7:18 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYfm4EAAoJEBzwKT+lPKRY7RkP/1Pd1MNlaCCLGAX/vVXPTsTi
ZO+zBM888owqJNcMgtoZnXHdJQnsX2ulfeFLJGEXtBby1L8zR/E+B2/lXFjlU2Bj
h3PHPKH3w7Lj/pKnWUoErSCiqKhIIg3XsfBZfIaHE+jSBvibO30luzUwbLWXgTkb
0sK/tmdvoautPEyXSo0X9bg0FCrFnmbv3pJhCz4kUPtpLKXb9ffQchitCshqu96d
jZF5RgAqP2U9j5au0GKsHwAbDVXdM/qd04DbJjcS19LIsRYXCrUvMduRYVaiA5KK
PbV9slZ23hLDrqI3nE/jR5MATl2HzeqLs7sVpYMWhWgMYst1cgFvIQVnVjKa1uah
CTlHhBYbzrtYHnZBdKcBN1wpMnpnM6HM9CZCyRvrG4AqUvmKhQx/OHoUbP8DH8uc
8JRgTskpYO2MESsiDAVRBIe1MN/jm/YbZVRikooCA5JgVUNQf9k2CyZy9oDqz25d
dAiMwKdZ8ZS6bhglGx2SJm9pePM+Kt5N9TiUE+TkTOsoLmqgiSm5SAXOuQMLzfI4
a1LMR72GDogxckMmumfjSRwwvkoEGqR6VrQ8dzfp+mhaYysRgHAbzxAe4ZWCl9Bz
7UFn8cHCMjNHOwBFbkcuuCXoaUpfLE4spauFiU8FFnkmrvs/BWiXTplh596fgzsE
MzaClwNfP/RGKNqi4fsc
=W1gG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYfm4EAAoJEBzwKT+lPKRY7RkP/1Pd1MNlaCCLGAX/vVXPTsTi
ZO+zBM888owqJNcMgtoZnXHdJQnsX2ulfeFLJGEXtBby1L8zR/E+B2/lXFjlU2Bj
h3PHPKH3w7Lj/pKnWUoErSCiqKhIIg3XsfBZfIaHE+jSBvibO30luzUwbLWXgTkb
0sK/tmdvoautPEyXSo0X9bg0FCrFnmbv3pJhCz4kUPtpLKXb9ffQchitCshqu96d
jZF5RgAqP2U9j5au0GKsHwAbDVXdM/qd04DbJjcS19LIsRYXCrUvMduRYVaiA5KK
PbV9slZ23hLDrqI3nE/jR5MATl2HzeqLs7sVpYMWhWgMYst1cgFvIQVnVjKa1uah
CTlHhBYbzrtYHnZBdKcBN1wpMnpnM6HM9CZCyRvrG4AqUvmKhQx/OHoUbP8DH8uc
8JRgTskpYO2MESsiDAVRBIe1MN/jm/YbZVRikooCA5JgVUNQf9k2CyZy9oDqz25d
dAiMwKdZ8ZS6bhglGx2SJm9pePM+Kt5N9TiUE+TkTOsoLmqgiSm5SAXOuQMLzfI4
a1LMR72GDogxckMmumfjSRwwvkoEGqR6VrQ8dzfp+mhaYysRgHAbzxAe4ZWCl9Bz
7UFn8cHCMjNHOwBFbkcuuCXoaUpfLE4spauFiU8FFnkmrvs/BWiXTplh596fgzsE
MzaClwNfP/RGKNqi4fsc
=W1gG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Yes, I think thread count should be reduced when those threads are idle
Is this right? Or it will not reduced?
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Monday, January 16, 2017 2:20 PM
To: Tomcat Users List
Subject: Re: FW: tomcat 8080 thread not reduced
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYfNaBAAoJEBzwKT+lPKRY3ZsP+wdrzjUHAVPoF8KXIAj+vz0O
lZ0zXBC2XID9Bh6dQRKvW+9k/RQRCuOrnZ+Z4qVdeo9jdtQMPGkQcpr5mw3m7rCZ
XefMU8KBsSl/31lBhl8ajxAUqpTx37dSUV6mUFVtVVEZdp2/+3Jy1slmEuO7+COJ
wUYtD7y4yk9oitxj0S3Omeglo+g00yJmTVgEJClCF19wYIn0uSfwZFgOpkftj2HO
ct1ndMa5WIUQYtQ6ueiOgIoZb4aEhhS69JilN0GZ1WZpdTUCj04bosnOJ94w8fPi
1+z/5GCAPVhLBYN+LTr/03EoC9u+gm7163+eIbGK8g/1GiNqY+m6plI7LMGaNy0j
3pfgitcK2Mte4w2T0yJpe87lwNOCrkVL4oXCmOGx8b/P5f9M2MukKTIfmRsT7Q/G
u4skc+LYCxVwIqsND/4DuBatAx8FSzi3UebHIJoBVOe22b6zPYKGaXUBo530dAvK
iVnBgzxIOvQuQr1pD6ylRjCmrmooIH6P8iknHX2DrKyaqEcdnR0g/iJnfuGeW+JO
VrbTWEcb29IrKsn4WGuglALijl+I1UCEvru5aTlvkXyWhePK1wlHYaupy69sy3a/
5z4LJdOebtN3QFr2I6hM54L0+bjjwCznlVa8b/6ky84ya/7tzWGoHqpqYod46HZZ
7E1OkTnDk67xhmh7iXbB
=e2NW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
Yes, I also think it should act like this, but it did not.
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Monday, January 16, 2017 2:33 PM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 16.01.2017 15:19, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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?
Hi. (André responding for "smith")
Maybe this :
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
--> minSpareThreads
?
(That's also the way I understand this : inactive threads disappear after a while, down to the number mentioned here - which is 10 by default. Not so ?)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYfNaBAAoJEBzwKT+lPKRY3ZsP+wdrzjUHAVPoF8KXIAj+vz0O
> lZ0zXBC2XID9Bh6dQRKvW+9k/RQRCuOrnZ+Z4qVdeo9jdtQMPGkQcpr5mw3m7rCZ
> XefMU8KBsSl/31lBhl8ajxAUqpTx37dSUV6mUFVtVVEZdp2/+3Jy1slmEuO7+COJ
> wUYtD7y4yk9oitxj0S3Omeglo+g00yJmTVgEJClCF19wYIn0uSfwZFgOpkftj2HO
> ct1ndMa5WIUQYtQ6ueiOgIoZb4aEhhS69JilN0GZ1WZpdTUCj04bosnOJ94w8fPi
> 1+z/5GCAPVhLBYN+LTr/03EoC9u+gm7163+eIbGK8g/1GiNqY+m6plI7LMGaNy0j
> 3pfgitcK2Mte4w2T0yJpe87lwNOCrkVL4oXCmOGx8b/P5f9M2MukKTIfmRsT7Q/G
> u4skc+LYCxVwIqsND/4DuBatAx8FSzi3UebHIJoBVOe22b6zPYKGaXUBo530dAvK
> iVnBgzxIOvQuQr1pD6ylRjCmrmooIH6P8iknHX2DrKyaqEcdnR0g/iJnfuGeW+JO
> VrbTWEcb29IrKsn4WGuglALijl+I1UCEvru5aTlvkXyWhePK1wlHYaupy69sy3a/
> 5z4LJdOebtN3QFr2I6hM54L0+bjjwCznlVa8b/6ky84ya/7tzWGoHqpqYod46HZZ
> 7E1OkTnDk67xhmh7iXbB
> =e2NW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 16.01.2017 15:19, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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?
Hi. (Andr� responding for "smith")
Maybe this :
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
--> minSpareThreads
?
(That's also the way I understand this : inactive threads disappear after a while, down to
the number mentioned here - which is 10 by default. Not so ?)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYfNaBAAoJEBzwKT+lPKRY3ZsP+wdrzjUHAVPoF8KXIAj+vz0O
> lZ0zXBC2XID9Bh6dQRKvW+9k/RQRCuOrnZ+Z4qVdeo9jdtQMPGkQcpr5mw3m7rCZ
> XefMU8KBsSl/31lBhl8ajxAUqpTx37dSUV6mUFVtVVEZdp2/+3Jy1slmEuO7+COJ
> wUYtD7y4yk9oitxj0S3Omeglo+g00yJmTVgEJClCF19wYIn0uSfwZFgOpkftj2HO
> ct1ndMa5WIUQYtQ6ueiOgIoZb4aEhhS69JilN0GZ1WZpdTUCj04bosnOJ94w8fPi
> 1+z/5GCAPVhLBYN+LTr/03EoC9u+gm7163+eIbGK8g/1GiNqY+m6plI7LMGaNy0j
> 3pfgitcK2Mte4w2T0yJpe87lwNOCrkVL4oXCmOGx8b/P5f9M2MukKTIfmRsT7Q/G
> u4skc+LYCxVwIqsND/4DuBatAx8FSzi3UebHIJoBVOe22b6zPYKGaXUBo530dAvK
> iVnBgzxIOvQuQr1pD6ylRjCmrmooIH6P8iknHX2DrKyaqEcdnR0g/iJnfuGeW+JO
> VrbTWEcb29IrKsn4WGuglALijl+I1UCEvru5aTlvkXyWhePK1wlHYaupy69sy3a/
> 5z4LJdOebtN3QFr2I6hM54L0+bjjwCznlVa8b/6ky84ya/7tzWGoHqpqYod46HZZ
> 7E1OkTnDk67xhmh7iXbB
> =e2NW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYfNaBAAoJEBzwKT+lPKRY3ZsP+wdrzjUHAVPoF8KXIAj+vz0O
lZ0zXBC2XID9Bh6dQRKvW+9k/RQRCuOrnZ+Z4qVdeo9jdtQMPGkQcpr5mw3m7rCZ
XefMU8KBsSl/31lBhl8ajxAUqpTx37dSUV6mUFVtVVEZdp2/+3Jy1slmEuO7+COJ
wUYtD7y4yk9oitxj0S3Omeglo+g00yJmTVgEJClCF19wYIn0uSfwZFgOpkftj2HO
ct1ndMa5WIUQYtQ6ueiOgIoZb4aEhhS69JilN0GZ1WZpdTUCj04bosnOJ94w8fPi
1+z/5GCAPVhLBYN+LTr/03EoC9u+gm7163+eIbGK8g/1GiNqY+m6plI7LMGaNy0j
3pfgitcK2Mte4w2T0yJpe87lwNOCrkVL4oXCmOGx8b/P5f9M2MukKTIfmRsT7Q/G
u4skc+LYCxVwIqsND/4DuBatAx8FSzi3UebHIJoBVOe22b6zPYKGaXUBo530dAvK
iVnBgzxIOvQuQr1pD6ylRjCmrmooIH6P8iknHX2DrKyaqEcdnR0g/iJnfuGeW+JO
VrbTWEcb29IrKsn4WGuglALijl+I1UCEvru5aTlvkXyWhePK1wlHYaupy69sy3a/
5z4LJdOebtN3QFr2I6hM54L0+bjjwCznlVa8b/6ky84ya/7tzWGoHqpqYod46HZZ
7E1OkTnDk67xhmh7iXbB
=e2NW
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
Hi.
I can find nothing really wrong in your configuration below.
But, what happens if in this section :
> <Connector port="8080" protocol="HTTP/1.1"
> maxThreads="300" connectionTimeout="20000"
> redirectPort="8443" />
you change the connectionTimeout to 3000 (= 3 seconds, instead of the above 20 seconds) ?
Do you still see the number of threads remaining at the maximum ?
See : http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Standard_Implementation
--> connectionTimeout
and the fact that it is also the default for
keepAliveTimeout
On 14.01.2017 07:30, smith wrote:
> The server.xml:
>
> <?xml version='1.0' encoding='utf-8'?>
> <!--
> Licensed to the Apache Software Foundation (ASF) under one or more
> contributor license agreements. See the NOTICE file distributed with
> this work for additional information regarding copyright ownership.
> The ASF licenses this file to You under the Apache License, Version 2.0
> (the "License"); you may not use this file except in compliance with
> the License. You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing, software
> distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> See the License for the specific language governing permissions and
> limitations under the License.
> -->
> <!-- Note: A "Server" is not itself a "Container", so you may not
> define subcomponents such as "Valves" at this level.
> Documentation at /docs/config/server.html
> -->
> <Server port="8005" shutdown="SHUTDOWN">
> <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
> <!-- Security listener. Documentation at /docs/config/listeners.html
> <Listener className="org.apache.catalina.security.SecurityListener" />
> -->
> <!--APR library loader. Documentation at /docs/apr.html -->
> <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
> <!-- Prevent memory leaks due to use of particular java/javax APIs-->
> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
> <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
>
> <!-- Global JNDI resources
> Documentation at /docs/jndi-resources-howto.html
> -->
> <GlobalNamingResources>
> <!-- Editable user database that can also be used by
> UserDatabaseRealm to authenticate users
> -->
> <Resource name="UserDatabase" auth="Container"
> type="org.apache.catalina.UserDatabase"
> description="User database that can be updated and saved"
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> pathname="conf/tomcat-users.xml" />
> </GlobalNamingResources>
>
> <!-- A "Service" is a collection of one or more "Connectors" that share
> a single "Container" Note: A "Service" is not itself a "Container",
> so you may not define subcomponents such as "Valves" at this level.
> Documentation at /docs/config/service.html
> -->
> <Service name="Catalina">
>
> <!--The connectors can use a shared executor, you can define one or more named thread pools-->
> <!--
> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
> maxThreads="150" minSpareThreads="4"/>
> -->
>
>
> <!-- A "Connector" represents an endpoint by which requests are received
> and responses are returned. Documentation at :
> Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
> Java AJP Connector: /docs/config/ajp.html
> APR (HTTP/AJP) Connector: /docs/apr.html
> Define a non-SSL HTTP/1.1 Connector on port 8080
> -->
> <Connector port="8080" protocol="HTTP/1.1"
> maxThreads="300" connectionTimeout="20000"
> redirectPort="8443" />
> <!-- A "Connector" using the shared thread pool-->
> <!--
> <Connector executor="tomcatThreadPool"
> port="8080" protocol="HTTP/1.1"
> connectionTimeout="20000"
> redirectPort="8443" />
> -->
> <!-- Define a SSL HTTP/1.1 Connector on port 8443
> This connector uses the NIO implementation that requires the JSSE
> style configuration. When using the APR/native implementation, the
> OpenSSL style configuration is required as described in the APR/native
> documentation -->
> <!--
> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS" />
> -->
>
> <!-- Define an AJP 1.3 Connector on port 8009 -->
> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
>
>
> <!-- An Engine represents the entry point (within Catalina) that processes
> every request. The Engine implementation for Tomcat stand alone
> analyzes the HTTP headers included with the request, and passes them
> on to the appropriate Host (virtual host).
> Documentation at /docs/config/engine.html -->
>
> <!-- You should set jvmRoute to support load-balancing via AJP ie :
> <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
> -->
> <Engine name="Catalina" defaultHost="localhost">
>
> <!--For clustering, please take a look at documentation at:
> /docs/cluster-howto.html (simple how to)
> /docs/config/cluster.html (reference documentation) -->
> <!--
> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
> -->
>
> <!-- Use the LockOutRealm to prevent attempts to guess user passwords
> via a brute-force attack -->
> <Realm className="org.apache.catalina.realm.LockOutRealm">
> <!-- This Realm uses the UserDatabase configured in the global JNDI
> resources under the key "UserDatabase". Any edits
> that are performed against this UserDatabase are immediately
> available for use by the Realm. -->
> <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
> resourceName="UserDatabase"/>
> </Realm>
>
> <Host name="localhost" appBase="webapps"
> unpackWARs="true" autoDeploy="true">
>
> <!-- SingleSignOn valve, share authentication between web applications
> Documentation at: /docs/config/valve.html -->
> <!--
> <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
> -->
>
> <!-- Access log processes all example.
> Documentation at: /docs/config/valve.html
> Note: The pattern used is equivalent to using pattern="common" -->
>
> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
> prefix="localhost_access_log" suffix=".txt"
> pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
>
> <Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
> </Host>
> </Engine>
> </Service>
> </Server>
>
> -----Original Message-----
> From: Andr� Warnier (tomcat) [mailto:aw@ice-sa.com]
> Sent: Friday, January 13, 2017 10:42 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: tomcat 8080 thread not reduced
>
> On 13.01.2017 09:38, smith wrote:
>>
>>
>>
>>
>> From: smith [mailto:smith.hua@zoom.us]
>> Sent: Tuesday, January 10, 2017 9:57 AM
>> To: 'users'
>> Subject: tomcat 8080 thread not reduced
>>
>>
>>
>> Hi,
>>
>>
>>
>> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>>
>> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>>
>> When will the thread reduce?
>>
>>
>>
>>
>>
>> Best regards
>>
>> Smith
>>
>>
>
> Hi.
>
> Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
> Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: FW: tomcat 8080 thread not reduced
Posted by smith <sm...@zoom.us>.
The server.xml:
<?xml version='1.0' encoding='utf-8'?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" at this level.
Documentation at /docs/config/server.html
-->
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<!-- Security listener. Documentation at /docs/config/listeners.html
<Listener className="org.apache.catalina.security.SecurityListener" />
-->
<!--APR library loader. Documentation at /docs/apr.html -->
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<!-- Global JNDI resources
Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<!-- A "Service" is a collection of one or more "Connectors" that share
a single "Container" Note: A "Service" is not itself a "Container",
so you may not define subcomponents such as "Valves" at this level.
Documentation at /docs/config/service.html
-->
<Service name="Catalina">
<!--The connectors can use a shared executor, you can define one or more named thread pools-->
<!--
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="150" minSpareThreads="4"/>
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="300" connectionTimeout="20000"
redirectPort="8443" />
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the NIO implementation that requires the JSSE
style configuration. When using the APR/native implementation, the
OpenSSL style configuration is required as described in the APR/native
documentation -->
<!--
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<!-- An Engine represents the entry point (within Catalina) that processes
every request. The Engine implementation for Tomcat stand alone
analyzes the HTTP headers included with the request, and passes them
on to the appropriate Host (virtual host).
Documentation at /docs/config/engine.html -->
<!-- You should set jvmRoute to support load-balancing via AJP ie :
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">
-->
<Engine name="Catalina" defaultHost="localhost">
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h,%t,%m,%U,%H,%s,%B,%D,%{User-Agent}i" />
<Context path="" allowLinking="true" crossContext="true" docBase="/****/t" sessionCookieName="****" />
</Host>
</Engine>
</Service>
</Server>
-----Original Message-----
From: André Warnier (tomcat) [mailto:aw@ice-sa.com]
Sent: Friday, January 13, 2017 10:42 AM
To: users@tomcat.apache.org
Subject: Re: FW: tomcat 8080 thread not reduced
On 13.01.2017 09:38, smith wrote:
>
>
>
>
> From: smith [mailto:smith.hua@zoom.us]
> Sent: Tuesday, January 10, 2017 9:57 AM
> To: 'users'
> Subject: tomcat 8080 thread not reduced
>
>
>
> Hi,
>
>
>
> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>
> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>
> When will the thread reduce?
>
>
>
>
>
> Best regards
>
> Smith
>
>
Hi.
Please copy/paste your complete server.xml configuration file (confidential things removed), so that we could have a useful look at it.
Please edit *only* the confidential things, not entire sections. Often, the issue is in the details.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: FW: tomcat 8080 thread not reduced
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 13.01.2017 09:38, smith wrote:
>
>
>
>
> From: smith [mailto:smith.hua@zoom.us]
> Sent: Tuesday, January 10, 2017 9:57 AM
> To: 'users'
> Subject: tomcat 8080 thread not reduced
>
>
>
> Hi,
>
>
>
> We have installed Apache Tomcat/8.0.14, and found that after one period of time, the thread count for 8080(our port published) goes to 120 and never reduced even the busy count is only 3-4.
>
> Why? Tomcat8 not reduced the thread pool even the thread is idle, and the minSpareThreads for tomcat8 default is only 10.
>
> When will the thread reduce?
>
>
>
>
>
> Best regards
>
> Smith
>
>
Hi.
Please copy/paste your complete server.xml configuration file (confidential things
removed), so that we could have a useful look at it.
Please edit *only* the confidential things, not entire sections. Often, the issue is in
the details.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org