tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Connector Setting Problem in tomcat 6.0.29
Date Sun, 07 Nov 2010 12:29:44 GMT
On 07/11/2010 01:27, Jim Riggs wrote:
> On Nov 6, 2010, at 2:17 PM, Christopher Schultz wrote:
>=20
>>> I believe (if I heard it correctly), either Mark T. or Tim F.
>>> explained at ApacheCon this week that the minimum is not immediate.
>>> It needs to build up to that level.  So, when you start Tomcat, you
>>> won't immediately fire up 150 threads for the executor pool, but once=

>>>> =3D 150 threads are created in the process of serving requests, it
>>> will always keep a minimum of 150 for you.
>>
>> If that's the case, I find that surprising. I always like to avoid
>> violating the principle of least surprise. minSpareThreads as a name
>> implies to me that those spares are /always/ available, even immediate=
ly
>> after startup.
>=20
> Chris -
>=20
> If you look in org.apache.catalina.core.StandardThreadExecutor, you wil=
l see that it is using a ThreadPoolExecutor.  setMinSpareThreads() calls =
setCorePoolSize() in the ThreadPoolExecutor.  If you read the javadoc for=
 ThreadPoolExecutor, specifically the subsections labeled "Core and maxim=
um pool sizes" and "On-demand construction", you will see that the thread=
s are created on demand unless you use prestartCoreThread()/prestartAllCo=
reThreads(), which Tomcat does not.
>=20
> So, although it may seem surprising or even counterintuitive, all 150 w=
ill not be fired up on startup.  Perhaps we could add a separate attribut=
e on the Executor (e.g. startThreads)?  Then Tomcat would have a paradigm=
 similar to httpd's Start(Servers|Threads) and MinSpare(Servers|Threads).=
  Any interest in such an attribute?  It would be fairly simple to roll a=
 patch for it...

Making this less surprising and adding an attribute to prestart some
threads would be a good idea IMHO.


p

Mime
View raw message