-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 12/5/12 12:17 AM, Konstantin Kolinko wrote: > 2012/12/3 Caldarale, Charles R <chuck.caldar...@unisys.com>: >>> From: Weixiang [mailto:kurt.weixi...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
