tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [OT] Tomcat7.0-Setting property 'threadPriority' did not find a matching property
Date Wed, 05 Dec 2012 16:28:21 GMT
Hash: SHA1


On 12/5/12 12:17 AM, Konstantin Kolinko wrote:
> 2012/12/3 Caldarale, Charles R <>:
>>> From: Weixiang [] Subject:
>>> Tomcat7.0-Setting property 'threadPriority' did not find a
>>> matching property
>>> I config in my server.xml for a HTTP Connector named "MGMT":
>>> threadPriority="java.lang.Thread#Thread.MAX_PRIORITY"
>> The documentation may give the impression that you can set the
>> value of the threadPriority attribute to a string referring to
>> some static field, but that is not actually the case.  You must
>> supply a numeric value here, which will normally be 10 for the
>> maximum.  You can write a simple Java program to display the
>> values of Thread.MIN_PRIORITY and Thread.MAX_PRIORITY, and choose
>> a number within that range.
>> class ThreadPriority { static public void main(String args[])
>> throws Exception { System.out.format("thread priorities: MIN %d,
>> NORM %d, MAX %d%n", Thread.MIN_PRIORITY, Thread.MIN_PRIORITY,
>> Thread.MAX_PRIORITY); } }
>> The JDK 7 Javadoc includes a description for the priority values,
>> but it doesn't appear to be completely accurate: 
> The MIN/NORM/MAX_PRIORITY constants in the Thread class are "final 
> static" and thus they are evaluated and inlined at compile time
> and cannot differ between systems.

Yeah, I was surprised long ago to find that javac converts foreign
static final primitives into local constants in the class file's
constant pool. That means that, once compiled, a client class has the
values from compile-time and if the defining-class is changed to have
a different value and the client class isn't recompiled, they will be
out of sync.

So much for what feels like dynamic linking.

A bunch of years ago, I started monkeying around with the JVM,
compiler, disassembler (jad) and a bytecode assembler (I have
forgotten which one... or maybe I wrote one). I found that you could
prevent the compiler from inlining constants from other classes by
using this technique:

public static int SOME_CONSTANT;

static {

In that case, references to SomeClass.SOME_CONSTANT in another class
are fetched at runtime using a getfield operation, rather than loading
from the local class's constant pool.

I also found out that the JVM allows you to throw any kind of
reference type, not just exceptions (kinda like C++). I can't remember
if I was able to catch any of those types, though.

I hope this information is interesting to someone. I expect that Chuck
already knows all of this.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with undefined -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message