-----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 > -- 从myMail的Android专用app所发送 星期三, 18 一月 2017, 06:08下午 +08:00 发件人 > André Warnier (tomcat) a...@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:a...@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:pbus...@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:a...@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:a...@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) a...@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:a...@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....@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-unsubscr...@tomcat.apache.org For >>>>>>>>>> additional commands, e-mail: >>>>>>>>>> users-h...@tomcat.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------- - ---- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - ---- >>>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: >>>>>>>>>> users-unsubscr...@tomcat.apache.org For >>>>>>>>>> additional commands, e-mail: >>>>>>>>>> users-h...@tomcat.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- - ---- >>>>>>>>> >>>>>>>>> >>>>>>>>> - --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>>>>> For additional commands, e-mail: >>>>>>>>> users-h...@tomcat.apache.org >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- - ---- >>>>>>> >>>>>>> >>>>>>> - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>>> For additional commands, e-mail: >>>>>>> users-h...@tomcat.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- - ---- >>>>>>> >>>>>>> >>>>>>> - - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>>> For additional commands, e-mail: >>>>>>> users-h...@tomcat.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- - ---- >>>>>> >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>> For additional commands, e-mail: >>>>>> users-h...@tomcat.apache.org >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- - ---- >>>>>> >>>>>> >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>> For additional commands, e-mail: >>>>>> users-h...@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-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: >>>> users-h...@tomcat.apache.org >>>> >>>> >>>> >>>> ------------------------------------------------------------------- - -- >>>> >>>> >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: >>>> users-h...@tomcat.apache.org >>>> >>> >>> >>> -------------------------------------------------------------------- - - >>> >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >>> >>> -------------------------------------------------------------------- - - >>> >>> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
