On 07/11/2010 01:27, Jim Riggs wrote: > On Nov 6, 2010, at 2:17 PM, Christopher Schultz wrote: > >>> 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 >>>> = 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 immediately >> after startup. > > Chris - > > If you look in org.apache.catalina.core.StandardThreadExecutor, you will 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 maximum > pool sizes" and "On-demand construction", you will see that the threads are > created on demand unless you use > prestartCoreThread()/prestartAllCoreThreads(), which Tomcat does not. > > So, although it may seem surprising or even counterintuitive, all 150 will > not be fired up on startup. Perhaps we could add a separate attribute 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
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
