Re: [OT] Tomcat7.0-Setting property 'threadPriority' did not find a matching property

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Konstantin,

On 12/5/12 12:17 AM, Konstantin Kolinko wrote:
> 2012/12/3 Caldarale, Charles R <Ch...@unisys.com>:
>>> From: Weixiang [mailto:kurt.weixiang@huawei.com] 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: 
>> http://docs.oracle.com/javase/7/docs/api/constant-values.html#java.lang.Thread.MAX_PRIORITY
>
>> 
> 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 {
  SOME_CONSTANT = 4;
}

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC/diUACgkQ9CaO5/Lv0PCq5ACfdK4RlKomC2DH1lf53C1kOHzc
UbAAn3jt5Oci37BFF5ovCWE7wp6r2jci
=hsrF
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org