it is not possible to tune quality of http services (responsiveness) through thread priority. other threads in the web app are of various priority than the http connector and we want the connector to be of a higher/lower priority. 1- add connector thread pool property to server.xml to set initial thread priority. 2- additionnally, we would like a tomcat public API (perfectly knowing that it is not jsdk2.x), maybe jmx but that overkill, to vary connector's thread pool threads priorities according to application specific knowledge.
Quite frankly, thread priority is a big lie (at least from Java). Look at the javadocs.
Euh.. No. Sorry. (suns statements in javadoc about thread are known to be very forgiving for JVM implementors. Most if not all serious jvm have correct priorities.) There are plenty of JVMs out there that do correctly implements priority. And thrust me, it works. Here are some examples. Please verify by yourself. -screen updater toggles back and forth between prio 4 and 6. It help propmptness of drawing. -finalizer has low prio, for obvious reason. It does run seldomly, as expected in idle times. -SEDA architecture like sandstorm works great! I myself created a seda thread manager based on priority and load detection. It runs very nicely on sun, ibm, jrockit JVM, on both win32 and linux platform. Besides, I raise the tomcat connector threads in a dirty way: enumerate thread, match name with regex, and raise prio to 7 (because I use prio 1 to 6 for sandstorm). Trust me, it really balances stage & queue load and work well. And with that tomcat prio raised, my web UI is responsive and I keep the control. In other systems, with jmx timer and with container sheduling JSR 236 titled "Timer for Application Servers" http://jcp.org/en/jsr/detail?id=236 thread priority will become a serious concern. Please consider this RFE with "normal priority" (hehehe!)
Done. Need minor help from Amy Roh or another admin webapp expert on the writing of modified configuration, will post on tomcat-dev, but the code is there and seems to be working.
for cross-ref purpose: see bug #27616
Priority not applied. Run tomcat in a debugger, like eclipse, pause processors/monitors threads, look at first stackframe (thread run()), the variable 'this' (the thread). look at the priority field: still = 5 (normal prio) instead of prescribed value. Expected to see the monitor thread and the processors threads at priority 8 in the case below. <Connector port="1026" maxThreads="15" minSpareThreads="2" maxSpareThreads="5" enableLookups="false" acceptCount="100" debug="1" connectionTimeout="20000" disableUploadTimeout="true" threadPriority="8" redirectPort="18443" /> Thr: d P=05 ALIVE "http-1026-Processor1" (org.apache.tomcat.util.threads.ThreadWithAttributes) Thr: d P=05 ALIVE "http-1026-Processor2" (org.apache.tomcat.util.threads.ThreadWithAttributes) Thr: P=05 ALIVE "http-1026-Monitor"
against 5.0.27
Ooops, I forgot the actual Thread#setPriority call. Sorry about that ;) Fixed in both TOMCAT_5_0 and CVS HEAD branches.