Tomcat Unix daemon (jsvc) - problem with compilation
Hello everybody. I encountered a problem with compilation of Unix daemon (jsvc) against IBM Java from Tomcat 7.0.40. I used these commands: cd /opt/tomcat/bin tar xvfz commons-daemon-native.tar.gz cd commons-daemon-1.0.x-native-src/unix /configure and I got this output: *** Current host *** checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib checking for strip... strip *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for JDK os include directory... Cannot find jni_md.h in /usr/lib/jvm/java-1.6.0-ibm.x86_64/ configure: error: You should retry --with-os-type=SUBDIR I found information that the reason is: IBM java uses $JAVA_HOME/include/jniport.h instead of $JAVA_HOME/include/jni_md.h in Oracle java. When I created a link jni_md.h to jniport.h I can successfully compile jsvc but when I try to start Tomcat server I have a problem with class loading (Java class not found). Is there some fix or recommendation for compilation Tomcat Unix daemon with IBM Java? Thank you very much for your help. Best regards, J. Fikker. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
Hi All, I tested Tomcat 7.0.40 with Solaris x86. It gave better CPU performance than Tomcat 7.0.30 . It was able to handle 70K requests at 45% CPU utilization which is still behind my bench mark of 70k requests at 25-30% utilization with Tomcat 6. I also tested with Tomcat 6.0.37 and the results were more or less same as Tomcat 6.0.18 One thing I observed,I ran 3 clients pointing to 3 different static HTML pages. With Tomcat 6(both 6.0.18 and 6.0.37) each client gave me a concurrency of 48k req/sec at 50-55% CPU utilization. However when I ran the same test case for Tomcat 7(7.0.40 and 7.0.30) the req/sec were divided b/w the clients and the total concurrency was consistent around 70k with 45% utilization. Now no matter how many clients I run,the req/sec is constant. This is a bit strange. What could possibly be the reason? I am not sure I would be able to upgrade to Tomcat 7 under these circumstances. Thanks. From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 22 May 2013 7:30 PM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/21/13 11:03 PM, Chirag Dewan wrote: I was monitoring the CPU utilization specifically. I can compromise on 1 less transactions/sec,but 80-90% utilization is not good. While it's nice to reduce resource utilization as much as possible, why would you want your server to run at 25% CPU all the time? That's a waste of 75% of the CPU available. The test you are performing sounds like a peak-load test (100 simultaneous connections is pretty decent load). At peak load, you have 10-20% breathing room before your CPU can't keep up. Sounds like you have an appropriately-sized server for the type of load you expect. Do you have some kind of performance benchmarks that you have to hit? I have configured 1000 max threads in the connector,and I am testing with 100 concurrent threads. So you have 10 times the number of threads available than necessary. Did you do that simply to make sure that the thread-pool wouldn't be the problem? What kind of connector are you using? Re-reading the thread it looks like you are using the BIO (default) connector. I'm not sure switching to NIO or APR would help raw throughput unless you are using SSL (switch to APR) or have lots of dropped keepalive connections (switch to NIO - or APR?). Well I tested a sample html page with Tomcat 6.0.18 and 7.0.30 on Solaris x86 server. The req/sec were almost the same for both,but CPU utilization for Tomcat 6 was 23-27% and for Tomcat 7 it was 80-90% consistently. What about Tomcat 6.0.37? On the other hand on a Linux system,the req/sec were a little higher in Tomcat 7 say 65k to 55k on tomcat 6 and the CPU utilization was the same for both 6 and 7. ... and what was that CPU utilization? My Jprofiler stack trace on Solaris is a lot different. As far as I have observed,for Tomcat 7 the stack Trace leads me to ResponseFacade.setContentType,which was not the behaviour in Tomcat 6. Can that be a bottleneck? See Mark's message: there have been some changes to how Tomcat performs a setContentType -- because the string actually needs to be parsed to see if there is a character encoding hiding in there, and the output writer may need it's encoding changed. You can see in the changelog (http://tomcat.apache.org/tomcat-7.0-doc/changelog.html) this entry under 7.0.33, which I think is the relevant part: The HTTP header parser added to address 52811 has been removed... Take a look at the references provided if you are interested in the details. Otherwise, just upgrade to 7.0.40 and try again. Or is there something platform dependent that I should take care of? There could be a bug in one of the JVMs, but this is fairly well-exercised code that you are talking about. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnM+NAAoJEBzwKT+lPKRYDo4P/2LGsApJTBj39lPKdshAYXba DwDWIllFM+fn/XRLsx2fTinBLPupWoGbGrPoVOA7xTTqrJVddJCfwbbmiS2RvcB5 kPMNn+baAWMN3f4z/5fVkXwVhuyfRNKMFNzL64N3hjuqhzMqQGBvoaUbKMq27bzt VzQiLiEC5mUJ4VsnUj+h4yWCFPv2JT7Q4tifneAX3F3ouOI6KqJ7y30LX2qz4xPp 4f/KDgQwMTxrsdDe2R3+dmBFZgo2sHuZZUggGCvTADmjAaPgikAWAO5Yov2tPVhf ZRLrn6s6VAQpRDPN6jNQbogWWw/zakDf8zPrTSjr/BQRrhF7+eRyr3/jWlA9UOkd rs/WIXm6URZjhbzdO7h0qkPOziSw9cekUt/cVUigd9N+Mgyp0YcDw8wtg6Hx0PJC Ig/nvuOB3ePxP01EPc0hXg3fw6GlwTSS0H5GRox0n5cvR83lDtGrzCvqZe+py6z4 JaKtA7FhcYcZrqZiiGMNVYsMcBL5CEr4gQztCbQscfltnTjCIQoM7BclQ+VMHDQI SfLEsMfNBix6ap88H335RAyGUyMbz1kWMtBv7+GvzEoBQ6GDfk39iDu2rLfFLiMi calZtW9asdFFQwpe87hdadPToOgFuyyAIm7EZpSWF69kh5nM6DXSEBGOhjCrc9OB QGR+cvRCWYnodpC4YZhm =NxRr -END PGP SIGNATURE- - To
Non-invasive configuration by extension?
Hi, I need to configure TomEE to work with SSL connections. I see Tomcat documentation talking about how to edit the server.xml file. Is it possible to supply a small fragment XML file that Tomcat's configuration includes, similar to the way Linux distros now have software that looks in conf.d files? That way I can have the original XML file untouched and merely extend it to our own needs? Otherwise I'm looking at having to merge in changes at later points - more work for us. Thanks, James
Re: Non-invasive configuration by extension?
2013/5/23 James Green james.mk.gr...@gmail.com: Hi, I need to configure TomEE to work with SSL connections. I see Tomcat documentation talking about how to edit the server.xml file. Is it possible to supply a small fragment XML file that Tomcat's configuration includes, similar to the way Linux distros now have software that looks in conf.d files? That way I can have the original XML file untouched and merely extend it to our own needs? Otherwise I'm looking at having to merge in changes at later points - more work for us. No. There is no such feature. Similar ones: 1. It is possible to use XML entities expansion to externalize some part of server.xml, but this involves editing of the original file, An example here: http://wiki.apache.org/tomcat/FAQ/Password 2. Application-specific settings go into application-specific META-INF/context.xml files. But you cannot use those to configure connectors. 3. You should know about running with separate CATALINA_HOME and CATALINA_BASE. You can leave pristine files in CATALINA_HOME/conf as a reference. Note that only the CATALINA_BASE ones will be used at run time. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Unix daemon (jsvc) - problem with compilation
Hi Jaroslav,
I have compiled the JSVC daemon on SUSE Linux Enterprise Server 11 SP2 (x64) on
the IBM JDK, like you are trying to do.
I would suggest that if your make of jsvc was successful. It would be
beneficial to see the error that your jsvc command is throwing. The daemon
does rely on some extra Java resources that should be loaded via the -classpath
argument. When starting Tomcat with JSVC, are you directing JSVC to load its
class files?
Here is one of my working configurations:
JAVA_OPTS=$JAVA_OPTS
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/etc/tomcat6/logging.properties
TOMCAT_MIN_HEAP=2048m #use a minimum heap of 2GB
TOMCAT_MAX_HEAP=3072m #use a maximum heap of 3GB
CATALINA_OPTS=${DEBUG_OPTS} -XX:MaxPermSize=256m -Xms$TOMCAT_MIN_HEAP
-Xmx$TOMCAT_MAX_HEAP
TOMCAT_USER=tomcat
CLASSPATH=/usr/lib64/jvm/java/lib/tools.jar:/usr/share/java/commons-logging-api.jar:$CATALINA_HOME/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
/sbin/startproc $JSVC_BIN \
-user $TOMCAT_USER \
-jvm $JSVC_JVM \
-home $JAVA_HOME \
-pidfile $JSVC_PID \
-outfile $CATALINA_BASE/logs/catalina.out \
-errfile $CATALINA_BASE/logs/catalina.out \
$JAVA_OPTS $CATALINA_OPTS \
-classpath $CLASSPATH \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
-Dcatalina.home=$CATALINA_BASE \
-Dcatalina.base=$CATALINA_BASE \
-Djava.io.tmpdir=$CATALINA_BASE/temp \
org.apache.catalina.startup.Bootstrap $@ start
---
Kenneth J. Erard
Application Specialist II
Information Technology Service
College Hall 210, Toledo Campus
567.661.2096 (Office) (08:00 AM to 05:00 PM)
419.419.8492 (Mobile)
kenneth_er...@owens.edu
Jaroslav Fikkerfik...@atlas.cz 5/23/2013 4:37 AM
Hello everybody.
I encountered a problem with compilation of Unix daemon (jsvc) against IBM Java
from Tomcat 7.0.40. I used these commands:
cd /opt/tomcat/bin
tar xvfz commons-daemon-native.tar.gz
cd commons-daemon-1.0.x-native-src/unix
/configure
and I got this output:
*** Current host ***
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking cached host system type... ok
*** C-Language compilation tools ***
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
checking for strip... strip
*** Host support ***
checking C flags dependant on host system type... ok
*** Java compilation tools ***
checking for JDK os include directory... Cannot find jni_md.h in
/usr/lib/jvm/java-1.6.0-ibm.x86_64/
configure: error: You should retry --with-os-type=SUBDIR
I found information that the reason is: IBM java uses
$JAVA_HOME/include/jniport.h instead of $JAVA_HOME/include/jni_md.h in Oracle
java. When I created a link jni_md.h to jniport.h I can successfully compile
jsvc but when I try to start Tomcat server I have a problem with class loading
(Java class not found).
Is there some fix or recommendation for compilation Tomcat Unix daemon with IBM
Java? Thank you very much for your help.
Best regards,
J. Fikker.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
On 5/23/2013 4:53 AM, Chirag Dewan wrote: Hi All, I tested Tomcat 7.0.40 with Solaris x86. It gave better CPU performance than Tomcat 7.0.30 . It was able to handle 70K requests at 45% CPU utilization which is still behind my bench mark of 70k requests at 25-30% utilization with Tomcat 6. I also tested with Tomcat 6.0.37 and the results were more or less same as Tomcat 6.0.18 One thing I observed,I ran 3 clients pointing to 3 different static HTML pages. With Tomcat 6(both 6.0.18 and 6.0.37) each client gave me a concurrency of 48k req/sec at 50-55% CPU utilization. However when I ran the same test case for Tomcat 7(7.0.40 and 7.0.30) the req/sec were divided b/w the clients and the total concurrency was consistent around 70k with 45% utilization. Now no matter how many clients I run,the req/sec is constant. This is a bit strange. What could possibly be the reason? Maybe you're saturating the bandwidth or maxing out some other resource not connected to the tomcats? I am not sure I would be able to upgrade to Tomcat 7 under these circumstances. Thanks. From: Christopher Schultzch...@christopherschultz.net To: Tomcat Users Listusers@tomcat.apache.org Sent: Wednesday, 22 May 2013 7:30 PM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/21/13 11:03 PM, Chirag Dewan wrote: I was monitoring the CPU utilization specifically. I can compromise on 1 less transactions/sec,but 80-90% utilization is not good. While it's nice to reduce resource utilization as much as possible, why would you want your server to run at 25% CPU all the time? That's a waste of 75% of the CPU available. The test you are performing sounds like a peak-load test (100 simultaneous connections is pretty decent load). At peak load, you have 10-20% breathing room before your CPU can't keep up. Sounds like you have an appropriately-sized server for the type of load you expect. Do you have some kind of performance benchmarks that you have to hit? I have configured 1000 max threads in the connector,and I am testing with 100 concurrent threads. So you have 10 times the number of threads available than necessary. Did you do that simply to make sure that the thread-pool wouldn't be the problem? What kind of connector are you using? Re-reading the thread it looks like you are using the BIO (default) connector. I'm not sure switching to NIO or APR would help raw throughput unless you are using SSL (switch to APR) or have lots of dropped keepalive connections (switch to NIO - or APR?). Well I tested a sample html page with Tomcat 6.0.18 and 7.0.30 on Solaris x86 server. The req/sec were almost the same for both,but CPU utilization for Tomcat 6 was 23-27% and for Tomcat 7 it was 80-90% consistently. What about Tomcat 6.0.37? On the other hand on a Linux system,the req/sec were a little higher in Tomcat 7 say 65k to 55k on tomcat 6 and the CPU utilization was the same for both 6 and 7. ... and what was that CPU utilization? My Jprofiler stack trace on Solaris is a lot different. As far as I have observed,for Tomcat 7 the stack Trace leads me to ResponseFacade.setContentType,which was not the behaviour in Tomcat 6. Can that be a bottleneck? See Mark's message: there have been some changes to how Tomcat performs a setContentType -- because the string actually needs to be parsed to see if there is a character encoding hiding in there, and the output writer may need it's encoding changed. You can see in the changelog (http://tomcat.apache.org/tomcat-7.0-doc/changelog.html) this entry under 7.0.33, which I think is the relevant part: The HTTP header parser added to address 52811 has been removed... Take a look at the references provided if you are interested in the details. Otherwise, just upgrade to 7.0.40 and try again. Or is there something platform dependent that I should take care of? There could be a bug in one of the JVMs, but this is fairly well-exercised code that you are talking about. - -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Need AccessLogValve results clarification
-Original Message- From: Vanga Palli, Ravindra Kumar [mailto:ravindra.vangapa...@hp.com] Sent: Wednesday, May 22, 2013 6:46 PM To: Tomcat Users List Subject: RE: Need AccessLogValve results clarification Note: I don't think the IP is PAT/NAT. It depends on how you log IP, if you used %h this will be a NAT address but if you use X-forward-for header then it is the actual client. Thanks, Ravi -Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Wednesday, May 22, 2013 3:31 PM To: 'Tomcat Users List' Subject: RE: Need AccessLogValve results clarification -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 22, 2013 5:24 PM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification On 22/05/2013 23:13, Vanga Palli, Ravindra Kumar wrote: The timer starts when the incoming socket is assigned to a thread. So, what you see in logs is a processing time but not queuing time. Not quite. The timer starts once the request line has been processed Mark Thanks, Ravi Thanks guys. I thought that was how it worked, but glad for the clarification. Now, if only I can figure out why the log shows the same request for the login.jsp from the same IP 8 times in the same second (all with a very long processing time). Note: I don't think the IP is PAT/NAT. Thanks Ravi, but I really meant the connection should be coming in without PAT/NAT based on what I know of the network topology (one of our client's networks). Plus, the recorded IP is in the 10.x.x.x subnet, so it's really doubtful, but I'm not totally ruling it out. If I remember correctly, the time in the log is the time when the entry was written, that is, when the request is completed. So it's possible the end-user connected once, then refreshed the page a number of times because it wasn't loading, resulting in multiple requests, all of which completed at the same time. Jeff You know, if it wasn't for end users, all software would run perfectly with great performance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Unix daemon (jsvc) - problem with compilation
Hi Kenneth,
Thank you very much for your mail. We use own script for start Tomcat server
with -classpath parameter that contains directory path /opt/tomcat/lib. We need
to use all JAR files from this directory but Tomcat ignore this syntax
(notwithstanding previous version runs correctly) and it understand only
exact JAR definition, for example -classpath
/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-util.jar,...
Where could be a cause of this problem? Why this version of Tomcat ignore
string -classpath /opt/tomcat/lib?
J. Fikker
---
Hi Jaroslav,
I have compiled the JSVC daemon on SUSE Linux Enterprise Server 11 SP2 (x64) on
the IBM JDK, like you are trying to do.
I would suggest that if your make of jsvc was successful. It would be
beneficial to see the error that your jsvc command is throwing. The daemon does
rely on some extra Java resources that should be loaded via the -classpath
argument. When starting Tomcat with JSVC, are you directing JSVC to load its
class files?
Here is one of my working configurations:
JAVA_OPTS=$JAVA_OPTS
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/etc/tomcat6/logging.properties
TOMCAT_MIN_HEAP=2048m #use a minimum heap of 2GB TOMCAT_MAX_HEAP=3072m #use a
maximum heap of 3GB CATALINA_OPTS=${DEBUG_OPTS} -XX:MaxPermSize=256m
-Xms$TOMCAT_MIN_HEAP
-Xmx$TOMCAT_MAX_HEAP TOMCAT_USER=tomcat
CLASSPATH=/usr/lib64/jvm/java/lib/tools.jar:/usr/share/java/commons-logging-api.jar:$CATALINA_HOME/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
/sbin/startproc $JSVC_BIN \ -user $TOMCAT_USER \ -jvm $JSVC_JVM \ -home
$JAVA_HOME \ -pidfile $JSVC_PID \ -outfile $CATALINA_BASE/logs/catalina.out \
-errfile $CATALINA_BASE/logs/catalina.out
\ $JAVA_OPTS $CATALINA_OPTS \ -classpath $CLASSPATH \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties
\ -Dcatalina.home=$CATALINA_BASE \ -Dcatalina.base=$CATALINA_BASE \
-Djava.io.tmpdir=$CATALINA_BASE/temp \ org.apache.catalina.startup.Bootstrap
$@ start
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chuck,
On 5/22/13 1:42 PM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Follow-up: Possible false-postive with
JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and
OracleTimeoutPollingThread
I suspect that the DriverManager will always be loaded by the
boot ClassLoader, since the default-dispatch for ClassLoaders is
to chekc the parent first, then check yourself. The
DriverManager is at the top-level (well, there is primordial, but
that doesn't really count) ClassLoader so you'll always get
that.
Terminology alert: you're confusing the boot class loader with the
system class loader, and have erroneously labeled the actual boot
class loader as primordial. Generally speaking, the boot class
loader is responsible for extracting JRE classes from rt.jar (and
others that come with the JRE), while the system class loader
deals with those specified by the java.class.path setting
(CLASSPATH for those still stuck on environment variables).
Thanks for the pedantry: I was in fact ignoring the difference between
the system and boot ClassLoaders. However, the primordial ClassLoader
does in fact exist, and does in fact load classes, and is not called
the boot ClassLoader.
Oracle describes the primordial ClassLoader as that which loads pretty
much everything in the java.* package space. Oracle also describes the
system ClassLoader as the delegation root ancestor of all class
loaders.[1]
In practice, the primordial class loader is identified by a null
reference (and is this difficult to inspect) and the system class
loader is represented by an ExtClassLoader. On top of that is an
AppClassLoader. I'll have to play around with some classes loaded via
endorsed directories to see if I can nail-down how to get a Class with
the ExtClassLoader as its class loader instead of AppClassLoader.
DriverManager's ClassLoader is in fact null, the primordial class loader.
You can test it yourself, and discover the ClassLoader hierarchy in
play with a simple program:
public class ClassLoaderTest
{
public static void main(String[] args)
{
printClassLoaders(ClassLoaderTest.class);
printClassLoaders(Thread.class);
printClassLoaders(Object.class);
printClassLoaders(java.sql.DriverManager.class);
}
public static void printClassLoaders(Class cls)
{
ClassLoader cl = cls.getClassLoader();
System.out.println(*** ClassLoaders for
+ cls.getName() + ***);
while(null != cl)
{
System.out.println(ClassLoader[
+ cls.getName() + ]: + cl);
cl = cl.getParent();
}
System.out.println(ClassLoader[
+ cls.getName() + ]: + cl);
}
}
Run under two different JVMs on my laptop, I get:
$ java -showversion ClassLoaderTest
java version 1.7.0_17
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$AppClassLoader@63644028
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$ExtClassLoader@4ab03512
ClassLoader[ClassLoaderTest]: null
*** ClassLoaders for java.lang.Thread ***
ClassLoader[java.lang.Thread]: null
*** ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null
*** ClassLoaders for java.sql.DriverManager ***
ClassLoader[java.sql.DriverManager]: null
$ java ClassLoaderTest
java version 1.6.0_45
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01-451, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$AppClassLoader@a6eb38a
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$ExtClassLoader@69cd2e5f
ClassLoader[ClassLoaderTest]: null
*** ClassLoaders for java.lang.Thread ***
ClassLoader[java.lang.Thread]: null
*** ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null
*** ClassLoaders for java.sql.DriverManager ***
ClassLoader[java.sql.DriverManager]: null
$ java -showversion ClassLoaderTest
java version 1.6.0_45
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) Client VM (build 20.45-b01-451, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$AppClassLoader@cf2c80
ClassLoader[ClassLoaderTest]: sun.misc.Launcher$ExtClassLoader@1729854
ClassLoader[ClassLoaderTest]: null
*** ClassLoaders for java.lang.Thread ***
ClassLoader[java.lang.Thread]: null
*** ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null
*** ClassLoaders for java.sql.DriverManager ***
ClassLoader[java.sql.DriverManager]: null
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Re: Enable logging for JIoEndpoint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ravi,
On 5/22/13 3:46 PM, Vanga Palli, Ravindra Kumar wrote:
I have a simple question, how to ensure JIoEndpoint logs to
catalina.log fine when threads are maxed out?
I have read the tomcat logging documentation for tomcat
6.0.28/RHEL6.3.
Long question:
We are using tomcat 6.0.28, our goal is to figure out are we
maxing out on number of threads and I am looking at
JIoEndpiont.java source code and found the following code. So,
looks like JIoEndpoint logs whenever all the worker threads are
busy, if i receive conncurrent connections more than maxThreads in
server.xml , i should see this logging message in catalina.out. So,
how do i enable the logs for this class
org.apache.tomcat.util.net.JIoEndpoint.
if (curThreadsBusy == maxThreads) {
log.info(sm.getString(endpoint.info.maxThreads,
Integer.toString(maxThreads), address, Integer.toString(port))); }
I modified the following logging file:
tomcat/conf/logging.properties, added this entry to this file and
bounced the server.
cat /usr/Interwoven/tomcat/conf/logging.properties | grep -A 4 -B 3
JIo
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level
= INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers
= 5host-manager.org.apache.juli.FileHandler
org.apache.tomcat.util.net.JIoEndpoint.level = FINE
# For example, set the com.xyz.foo logger to only log SEVERE #
messages: #org.apache.catalina.startup.ContextConfig.level = FINE
I also configured the server.xml as follows:
Connector port=1776 maxThreads=8
threadPriority=MAX_PRIORITY minSpareThreads=3
maxSpareThreads=5 enableLookups=false acceptCount=512
debug=0 connectionTimeout=2 useURIValidationHack=false
disableUploadTimeout=true URIEncoding=UTF-8/
Then, i ran the test as follows which generates 500 concurrent
request, as there are only 8 max threads, i should get log message
that all threads are busy.
ab -n 1000 -c 500 http://localhost:1776/test.
In theory i should see the log message if i configured everything
correctly. So do you have any idea on what am i missing here. How
do i see the logging for JIoEndpoint class ?
Any insights would be helpful.
Thank you for asking a question with complete details!
I can confirm when setting:
org.apache.tomcat.util.net.JIoEndpoint.level=FINE
I get no output in catalina.out when I clearly should have reached
maxThreads.
I also tried:
org.apache.tomcat.level=FINE
...which gives me an incredible amount of output, but searching for
threads finds nothing. I was using Tomcat 7.0.39 which is quite
different but I suspect that the problem might be the same between
both versions.
I'll bet that you are using an executor, whether you know it or not.
I checked, and the StandardThreadExecutor class (in 6.0.x) has no
logging whatsoever. Sure enough, the ThreadPoolExecutor in 7.0.x also
has (virtually) no logging.
So, I suspect you will not be able to get this kind of information
sent to the log file. Instead, you'll have to obtain it through other
means (e.g. JMX).
I'm not sure why JIoEndpoint contains all of the code it does, as
IIRC, Tomcat 6 switched-over to using Executors for all thread
management, even if you don't define one yourself using Executor.
Tomcat 7's JIoEndpoint has none of the thread-management code that
still exists in Tomcat 6, so I suspect it has simply been deprecated
in 6.0 and removed entirely in 7.0.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRnjW6AAoJEBzwKT+lPKRYntwP/R89LI8anb5rXjRA9Eb005I4
1LXoclPKY4XjAIqpW+Y8Egjat1WDCBNXEqJE0fo2IVwA8rEiOmFZiuK/YGNywcWm
O8jDrbs8AbURMP1lHFTnuepLzKObIcr4mGvu3FMhthOimv8CHJtfAtVsc6e/1Di9
J/LfyDMdptOl9JEbit+qNiUVDbRDCst8Xj4hi9bnWNtB5KSCFXcA3DxKIsHueCeH
/GRHrBXBemsjXUu+HvW5UGTNdF5fgnt9a/cKT5iuwTd7wgQJYiOIeHXNKvFTrkZQ
tjMaKvlvCWT+9ZqHOUU5irvntHgnGOQTP6nu5RiVq482kwVHyysyBpy3aE7rI+48
qLRzc7831a9hbh2v5nREQ7jkj5J1Q7pDtJs4F2UKIxVPfK0OyegaqjOM6IxDp12p
QON9S9TeedC9c+r0HIoBwhR19qhwdEM40Xx7DLQW1Hmr0KAyOfSFBV1ZRIfWwc7m
cetoEdkFuor/CxYdtvYYvaEYG1x48LY9hAoJkZBYFp7m8vjc02AJgassqlxVijHF
qp4fHX2CaemOHOg6x+q5mDwZJpvyRNe5h2zkyU4k0HAo4wnEi1+QZ06yBQzju3QW
aIR7+/w2ZeGieddpZuJjkcCIxoZueTPgT4upTQKR3mdtVq7uMox+QMMj4ZKtHcLq
RgogWtxUA9BBy9cASzdF
=gDxl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
On 5/23/13 10:40 AM, Christopher Schultz wrote:
Chuck,
On 5/22/13 1:42 PM, Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Follow-up: Possible false-postive with
JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and
OracleTimeoutPollingThread
I suspect that the DriverManager will always be loaded by the
boot ClassLoader, since the default-dispatch for ClassLoaders
is to chekc the parent first, then check yourself. The
DriverManager is at the top-level (well, there is primordial,
but that doesn't really count) ClassLoader so you'll always
get that.
Terminology alert: you're confusing the boot class loader with
the system class loader, and have erroneously labeled the actual
boot class loader as primordial. Generally speaking, the boot
class loader is responsible for extracting JRE classes from
rt.jar (and others that come with the JRE), while the system
class loader deals with those specified by the java.class.path
setting (CLASSPATH for those still stuck on environment
variables).
Thanks for the pedantry: I was in fact ignoring the difference
between the system and boot ClassLoaders. However, the primordial
ClassLoader does in fact exist, and does in fact load classes, and
is not called the boot ClassLoader.
Oracle describes the primordial ClassLoader as that which loads
pretty much everything in the java.* package space. Oracle also
describes the system ClassLoader as the delegation root ancestor
of all class loaders.[1]
In practice, the primordial class loader is identified by a null
reference (and is this difficult to inspect) and the system class
loader is represented by an ExtClassLoader. On top of that is an
AppClassLoader. I'll have to play around with some classes loaded
via endorsed directories to see if I can nail-down how to get a
Class with the ExtClassLoader as its class loader instead of
AppClassLoader.
DriverManager's ClassLoader is in fact null, the primordial class
loader.
You can test it yourself, and discover the ClassLoader hierarchy
in play with a simple program:
public class ClassLoaderTest { public static void main(String[]
args) { printClassLoaders(ClassLoaderTest.class);
printClassLoaders(Thread.class); printClassLoaders(Object.class);
printClassLoaders(java.sql.DriverManager.class); } public static
void printClassLoaders(Class cls) { ClassLoader cl =
cls.getClassLoader();
System.out.println(*** ClassLoaders for + cls.getName() +
***); while(null != cl) { System.out.println(ClassLoader[ +
cls.getName() + ]: + cl); cl = cl.getParent(); }
System.out.println(ClassLoader[ + cls.getName() + ]: + cl); }
}
Run under two different JVMs on my laptop, I get:
$ java -showversion ClassLoaderTest java version 1.7.0_17
Java(TM) SE Runtime Environment (build 1.7.0_17-b02) Java
HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$AppClassLoader@63644028
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$ExtClassLoader@4ab03512
ClassLoader[ClassLoaderTest]: null *** ClassLoaders for
java.lang.Thread *** ClassLoader[java.lang.Thread]: null ***
ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null *** ClassLoaders for
java.sql.DriverManager *** ClassLoader[java.sql.DriverManager]:
null
$ java ClassLoaderTest java version 1.6.0_45 Java(TM) SE Runtime
Environment (build 1.6.0_45-b06-451-11M4406) Java HotSpot(TM)
64-Bit Server VM (build 20.45-b01-451, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$AppClassLoader@a6eb38a
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$ExtClassLoader@69cd2e5f
ClassLoader[ClassLoaderTest]: null *** ClassLoaders for
java.lang.Thread *** ClassLoader[java.lang.Thread]: null ***
ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null *** ClassLoaders for
java.sql.DriverManager *** ClassLoader[java.sql.DriverManager]:
null
$ java -showversion ClassLoaderTest java version 1.6.0_45
Java(TM) SE Runtime Environment (build 1.6.0_45-b06-451-11M4406)
Java HotSpot(TM) Client VM (build 20.45-b01-451, mixed mode)
*** ClassLoaders for ClassLoaderTest ***
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$AppClassLoader@cf2c80
ClassLoader[ClassLoaderTest]:
sun.misc.Launcher$ExtClassLoader@1729854
ClassLoader[ClassLoaderTest]: null *** ClassLoaders for
java.lang.Thread *** ClassLoader[java.lang.Thread]: null ***
ClassLoaders for java.lang.Object ***
ClassLoader[java.lang.Object]: null *** ClassLoaders for
java.sql.DriverManager *** ClassLoader[java.sql.DriverManager]:
null
-chris
Forgot my reference:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc5.html
-BEGIN PGP SIGNATURE-
Version:
RE: Where is a good SSL/TLS
OK Chris, I have to be nearing the finish line on mod_jk. Sitting in tomcat-connectors-1.2.37-src/native and running your configuration command I get: configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. I have the following packages: gcc.x86_64 4.4.7-3.el6 gcc-c++.x86_64 4.4.7-3.el6 httpd-devel.x86_64 0:2.2.15-28.el6_4 apr-devel.x86_640:1.3.9-5.el6_2 apr-util-devel.x86_64 0:1.3.9-3.el6_0.1 What am I missing? --- Thanks, Burton L. Smith w:801-584-6164 c:801-201-2897 -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, May 22, 2013 8:48 AM To: Tomcat Users List Subject: Re: Where is a good SSL/TLS -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Burton, On 5/22/13 10:36 AM, Christopher Schultz wrote: Instead, you'll need to install a handful of other packages to support it. From memory, I think you need a few of these, and possibly other dependencies: gcc (which you almost certainly already have installed) make (which you almost certainly already have installed) httpd-devel apr-devel - From a stock Amazon Linux 2013.03, I had to install: gcc gcc-c++ httpd-devel (apr-devel and apr-util are dependencies for httpd-devel) At this point, ./configure and make ran without a problem: $ ./configure --with-apxs=/usr/sbin/apxs $ make It took 18 seconds to build mod_jk 1.2.37 on a t1.micro instance. - -chris
Re: Need AccessLogValve results clarification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 5/22/13 6:30 PM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 22, 2013 5:24 PM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification On 22/05/2013 23:13, Vanga Palli, Ravindra Kumar wrote: The timer starts when the incoming socket is assigned to a thread. So, what you see in logs is a processing time but not queuing time. Not quite. The timer starts once the request line has been processed Mark Thanks, Ravi Thanks guys. I thought that was how it worked, but glad for the clarification. Now, if only I can figure out why the log shows the same request for the login.jsp from the same IP 8 times in the same second (all with a very long processing time). Note: I don't think the IP is PAT/NAT. Is the request GET? In any case, is there a Content-Length header? Is it non-zero? Maybe the client is sending a partial header and then waiting around before completing it. Tomcat would read the request line (and start the clock) and then wait around for the rest of the request before (likely) sending a fast response. Also, if you are talking about a mobile client, you may have trouble pushing data back to them quickly, resulting in a long response time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnjiLAAoJEBzwKT+lPKRYs1wP/iLH+OyuYLMpX2Ka7/0AQqb6 7kQFdtoVeWXjh2iRJiVvMfLVAWuDnmVhrZRNwQeL0wPWaCDxTxO8/mSDqik8695A lF+jgeb0DVQeadi7T2pum/NtT7bKtu8ZVVoHOFRs+9wSq2G8p5HL7LlVHQZdK3Vl q4ysAb5K+gtO//5YINJU3aF/bzyv4Y05FrQyXC/6NAD0xF5I8guTcmE5WBGUKFi4 zzHKctbR8T8a6ZQfWebNUHj80Lr/5uwf1e4yV9MUETWAJ0aLFpD8eJdTN5617dhK g0czEq51tSTId9XAKI9MtL+2ioz7OQm6dDgFHTbHXVTax//m7fKcgZ9TcqYvbCqh OyUFGdcJYMgjX2rWBaxhKca1l16NAxs0JW2eCtegsnVWzxQuJjQ9DEEgRbr5Zhry nRoxU9ZmbVd66HtQWR7S0eVt2AW8s0Lh9kkjOl15wH4gzUHDOLmtlr41eqvXmIME LUn4cCceFCU4XFSyq6EJSVflceI17mInri5x9UCEOqPpphdDAntrgb21Uje+ksTZ rVsR6LcyxV/vhErcv6tMrstPAsDMHvmJgawDgTkozdlPvlyqoYCP40dnneUcGKJg BDYAyE1tbDmrOhAMvqSsYroEf4pdvY/inwhGrACUJm7hM/DpHnNxGJTFmxyQzDGa EfrM4BckDLNlv/wLI69j =O5sT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 5/23/13 7:40 AM, David kerber wrote: On 5/23/2013 4:53 AM, Chirag Dewan wrote: Hi All, I tested Tomcat 7.0.40 with Solaris x86. It gave better CPU performance than Tomcat 7.0.30 . It was able to handle 70K requests at 45% CPU utilization which is still behind my bench mark of 70k requests at 25-30% utilization with Tomcat 6. I also tested with Tomcat 6.0.37 and the results were more or less same as Tomcat 6.0.18 One thing I observed,I ran 3 clients pointing to 3 different static HTML pages. With Tomcat 6(both 6.0.18 and 6.0.37) each client gave me a concurrency of 48k req/sec at 50-55% CPU utilization. However when I ran the same test case for Tomcat 7(7.0.40 and 7.0.30) the req/sec were divided b/w the clients and the total concurrency was consistent around 70k with 45% utilization. Now no matter how many clients I run,the req/sec is constant. This is a bit strange. What could possibly be the reason? Maybe you're saturating the bandwidth or maxing out some other resource not connected to the tomcats? Or hitting the limit of what Tomcat can actually handle in that environment. I would expect that, at some point, you'll hit a wall where (total) req/sec cannot go any higher no matter which way you adjust the attack (concurrency versus volume-per-client). Are you saying that with 2 clients (c=2) you can get 70K req/sec /per client/ and then also with c=50 you can still get 70K req/sec /per client/ meaning that Tomcat is serving 3.5M req/sec overall? That seems ... unlikely. I am not sure I would be able to upgrade to Tomcat 7 under these circumstances. Are you saying that Tomcat 7 can't serve your peak load requirements, or that you have some paper benchmarks you want to hit and since you can't hit them, Tomcat 7 is not an option? I'm still not sure why you are terribly concerned with CPU utilization. If you've got the CPU, why not use it? An idle machine is one that is costing you money. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnjoYAAoJEBzwKT+lPKRYmPMQALVEineIFqQXf6Wx4EaueozR OtwvQJ/bKIS9//JzUfAt4PmnEykfu0XD4xwzoumtCdLLZjIQNsHXc1M6WCvd+kUU ke4qgRdVJiK58ZKHKNqjEJbknLOm+qHOyNQMzKP3w84lt9kx4Vr/CayhD6YF+pGw o1aDlcWnjnwjJXA4+UWVxmLclFzyby3sC+iMd+Z+zSA5es5vDIU5zlyWDCbWVFv7 bbIEAU81StdSSugalPsSMtxXMUXpIeirOmIvdtJI2pLiuUI6RK0HiMW8IpPzjN3n yxERCLLSh+tupBk8Sb5PozCu1t7GNa24rvcmqP3rH2mFQ8oRVYmu1P0KZqTjL/yw zPBxFip1vTcGOZxiFPA7c9XafW983jcgK2r1Jqxg23R4+sxBeIaCyDuRK9TBtQTn KfgqTUG05SQSoLr67a0+VOjEQZzAU9G2cvAGAYBJU8RJcK1wAn0nO4Xg2Mz9T3fi t2kJCzeNV01SUPkJL5iAGdVO5HVHDvij1CO1OD6O0IqSDmL1RxQw75MyygEqc9GV U41lg5VtbtM3RGLdamJzmIZwSiczzmMW5XIvDFQ9Dc+gubAkScSdh99259KvTCYM 3wEMCBplx0q3jeyBTmNfZ0PvM7GE656GDSLr/KY1QuajBwP97rXsvFx1SDlv6hw7 OG9G6kOYVZQOxe8+mYLO =zEBg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where is a good SSL/TLS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Burton, On 5/23/13 11:39 AM, Smith, Burton wrote: OK Chris, I have to be nearing the finish line on mod_jk. Sitting in tomcat-connectors-1.2.37-src/native and running your configuration command I get: configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. I have the following packages: gcc.x86_64 4.4.7-3.el6 gcc-c++.x86_644.4.7-3.el6 httpd-devel.x86_64 0:2.2.15-28.el6_4 apr-devel.x86_64 0:1.3.9-5.el6_2 apr-util-devel.x86_64 0:1.3.9-3.el6_0.1 What am I missing? If you read config.log you'll find that /lib/cpp can't find the C++ compiler. I had to install this package (mentioned above, I might add), in order to get past that error: gcc-c++ Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnjpmAAoJEBzwKT+lPKRY2R0P/27c/7HcC4seqkYD3J1qrFLD TIdNMc6fJx4dxCg++iAUg86Va5CSJ/LuTfFRd3Q8mt3DAHxujJACPmCtpAoZeCLA B1L2te2idf0mJQQpcnNZUOTz1c4k3xQyEQIsb9DOPakO9pToN3dGno3uPOyZlK8W JivODGB6Ni+vouTRQ3CFNrMqJ2bq6ZloefhZRACvHcluGNMdgqyb38Mlvxp2NRp9 iV/S1Kfz5JPlYtzlt35KpRDbeI0Q+BFi0gT4PE8wjH+zecMgHsaQhLIUlusmtURu V3rzoIJ9NP4N9fSRrpQ7fLlCwB6R4o2pLhlDrmeF06w8GX1skBxhwRsG4Btn5sr8 Zj9g8uc8uUoZyD0lxqRF5Q+2RY6wQX5qTHM0ido18wdqO6jbbN8Sj3ncyQiAwfMA LsXSuxpH1NPS+Lk5KjH1cvfT76WvEfIZTehsY50RE1AoNj9yLoWvkpvoQf0M8Xjd T7eFH3OHbd0Hy3L9cXFu1seNLsavydhixSCIrwhLCIn18ye11RMixZfGYoCF6g2C +vQf45hruvZyR0rBSpR/VGAkxpG3t7fgjfDQpbh0B1SrZaMqC+XH2oH09KDaPDor gDO+gUBVFicdBQSuNPhaCYUHoWfzzpgPjc3r2iFnyivIEW2tc8dyGIq9I7+xvFoO 9Pg6DAvA00ZMLrqbyY+T =hgzP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread Thanks for the pedantry: I was in fact ignoring the difference between the system and boot ClassLoaders. However, the primordial ClassLoader does in fact exist, and does in fact load classes, and is not called the boot ClassLoader. What you're calling the primordial class loader _is_ the boot class loader, identified by a null reference. (The use of primordial in the page you referred to is unusual; it's known as the boot or bootstrap class loader in almost all other documentation.) It's responsible for more than just the java.* packages, since it also loads all the com.sun.*, sun.*, and other JVM-vendor supplied classes. I ignored the extensions class loader, since it's rarely used and was not pertinent to the topic. the system class loader is represented by an ExtClassLoader. On top of that is an AppClassLoader. What you're looking at is JVM-internal classes (hence the $ in the names), that just happen to be the ones chosen in current versions of the JVM. The name is an implementation detail; the internal class mechanism is used to handle privilege issues. The internal names should not be construed as descriptive of the class loader hierarchy. On top of that is an AppClassLoader. Only for programs that supply their own, such as Tomcat. My comments concerned the JVM itself, not Tomcat. DriverManager's ClassLoader is in fact null, the primordial class loader. Unless one configures a replacement DriverManager (I think there's a system property for that, but I'm not sure). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: permgen space increases every day
Thanks for the reply. do you ever actually run out of PermGen space, or are you just particularly worried about it happening? Yes I did ran out of PermGen space. So I am checking frequently whats the perm gen size and I see its increasing every day. Thanks I will try out you suggestion. -- View this message in context: http://tomcat.10.x6.nabble.com/permgen-space-increases-every-day-tp4999275p4999396.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Need AccessLogValve results clarification
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, May 23, 2013 10:41 AM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 5/22/13 6:30 PM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 22, 2013 5:24 PM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification On 22/05/2013 23:13, Vanga Palli, Ravindra Kumar wrote: The timer starts when the incoming socket is assigned to a thread. So, what you see in logs is a processing time but not queuing time. Not quite. The timer starts once the request line has been processed Mark Thanks, Ravi Thanks guys. I thought that was how it worked, but glad for the clarification. Now, if only I can figure out why the log shows the same request for the login.jsp from the same IP 8 times in the same second (all with a very long processing time). Note: I don't think the IP is PAT/NAT. Is the request GET? In any case, is there a Content-Length header? Is it non-zero? Maybe the client is sending a partial header and then waiting around before completing it. Tomcat would read the request line (and start the clock) and then wait around for the rest of the request before (likely) sending a fast response. Also, if you are talking about a mobile client, you may have trouble pushing data back to them quickly, resulting in a long response time. - -chris Chris - The logged request is GET /Login.jsp HTTP/1.1. The file itself is our login form, which pulls some values from the application static cache and one query back to the DB for a flag. No explicit Content-Length header that I can tell. The user hasn't even logged in yet. Suspicion is on the DB connection right now, or perhaps some other load-related problem. I'm still doing a detail review of the log. Wouldn't think it would be the DB response since the query is essentially select value from config_table where id='constant'; on a table with maybe 2 dozen records in it. That should be sub-ms response every time. We are seeing these in clusters of poor response time, and the time is several minutes (5-10). Jeff - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Unix daemon (jsvc) - problem with compilation
--
We need to use all JAR files from this directory but Tomcat ignore this syntax
(notwithstanding previous version runs correctly) and it understand only
exact JAR definition, for example -classpath
/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-util.jar,...
Where could be a cause of this problem? Why this version of Tomcat ignore
string -classpath /opt/tomcat/lib?
--
I'm not sure! I'm actually quite new to Tomcat, and don't have an answer. I
previously tried a pattern match (ex: CLASSPATH=/opt/classes/*.jar or
CLASSPATH=/opt/myclasses/*.*) without success, then switched to loading
specific JAR files. Your problem was exactly what I had experienced with JSVC
before I made the switch -- no classes found. Once I explicitly declared my
JAR files, JSVC was happy.
Perhaps someone with deeper knowledge of Tomcat and JSVC has an answer.
---
Kenneth J. Erard
Application Specialist II
Information Technology Service
College Hall 210, Toledo Campus
567.661.2096 (Office) (08:00 AM to 05:00 PM)
419.419.8492 (Mobile)
kenneth_er...@owens.edu
Jaroslav Fikkerfik...@atlas.cz 5/23/2013 10:18 AM
Hi Kenneth,
Thank you very much for your mail. We use own script for start Tomcat server
with -classpath parameter that contains directory path /opt/tomcat/lib. We need
to use all JAR files from this directory but Tomcat ignore this syntax
(notwithstanding previous version runs correctly) and it understand only
exact JAR definition, for example -classpath
/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-util.jar,...
Where could be a cause of this problem? Why this version of Tomcat ignore
string -classpath /opt/tomcat/lib?
J. Fikker
---
Hi Jaroslav,
I have compiled the JSVC daemon on SUSE Linux Enterprise Server 11 SP2 (x64) on
the IBM JDK, like you are trying to do.
I would suggest that if your make of jsvc was successful. It would be
beneficial to see the error that your jsvc command is throwing. The daemon does
rely on some extra Java resources that should be loaded via the -classpath
argument. When starting Tomcat with JSVC, are you directing JSVC to load its
class files?
Here is one of my working configurations:
JAVA_OPTS=$JAVA_OPTS
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/etc/tomcat6/logging.properties
TOMCAT_MIN_HEAP=2048m #use a minimum heap of 2GB TOMCAT_MAX_HEAP=3072m #use a
maximum heap of 3GB CATALINA_OPTS=${DEBUG_OPTS} -XX:MaxPermSize=256m
-Xms$TOMCAT_MIN_HEAP
-Xmx$TOMCAT_MAX_HEAP TOMCAT_USER=tomcat
CLASSPATH=/usr/lib64/jvm/java/lib/tools.jar:/usr/share/java/commons-logging-api.jar:$CATALINA_HOME/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
/sbin/startproc $JSVC_BIN \ -user $TOMCAT_USER \ -jvm $JSVC_JVM \ -home
$JAVA_HOME \ -pidfile $JSVC_PID \ -outfile $CATALINA_BASE/logs/catalina.out \
-errfile $CATALINA_BASE/logs/catalina.out
\ $JAVA_OPTS $CATALINA_OPTS \ -classpath $CLASSPATH \
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
-Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties
\ -Dcatalina.home=$CATALINA_BASE \ -Dcatalina.base=$CATALINA_BASE \
-Djava.io.tmpdir=$CATALINA_BASE/temp \ org.apache.catalina.startup.Bootstrap
$@ start
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
Chris, With c=1 it is 70k req/sec and with c=2 it is 35k in both i.e the total req/sec cannot be scaled beyond 70k. With Tomcat 6 it is 60k in both clients i.e total of 120k. I do not expect more than 75k req/sec being served by Tomcat 7,but its the benchmark set by Tomcat 6 which I can't overlook. As I said I wouldn't have mind 80-90 % utilization on peak load,but its the already running server performance which I am compelled to follow or even carry out more. Thanks. Sent from Yahoo! Mail on Android
RE: Need AccessLogValve results clarification
-Original Message- From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] Sent: Thursday, May 23, 2013 11:24 AM To: 'Tomcat Users List' Subject: RE: Need AccessLogValve results clarification -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, May 23, 2013 10:41 AM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 5/22/13 6:30 PM, Jeffrey Janner wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, May 22, 2013 5:24 PM To: Tomcat Users List Subject: Re: Need AccessLogValve results clarification On 22/05/2013 23:13, Vanga Palli, Ravindra Kumar wrote: The timer starts when the incoming socket is assigned to a thread. So, what you see in logs is a processing time but not queuing time. Not quite. The timer starts once the request line has been processed Mark Thanks, Ravi Thanks guys. I thought that was how it worked, but glad for the clarification. Now, if only I can figure out why the log shows the same request for the login.jsp from the same IP 8 times in the same second (all with a very long processing time). Note: I don't think the IP is PAT/NAT. Is the request GET? In any case, is there a Content-Length header? Is it non-zero? Maybe the client is sending a partial header and then waiting around before completing it. Tomcat would read the request line (and start the clock) and then wait around for the rest of the request before (likely) sending a fast response. Also, if you are talking about a mobile client, you may have trouble pushing data back to them quickly, resulting in a long response time. - -chris Chris - The logged request is GET /Login.jsp HTTP/1.1. The file itself is our login form, which pulls some values from the application static cache and one query back to the DB for a flag. No explicit Content-Length header that I can tell. The user hasn't even logged in yet. Suspicion is on the DB connection right now, or perhaps some other load-related problem. I'm still doing a detail review of the log. Wouldn't think it would be the DB response since the query is essentially select value from config_table where id='constant'; on a table with maybe 2 dozen records in it. That should be sub-ms response every time. We are seeing these in clusters of poor response time, and the time is several minutes (5-10). Jeff Don't think I'm going to worry too much about this right now. Most of the response codes on those requests were 500s, so I figure the EU was frustrated at the long response time and kept hitting refresh. And the client has admitted that there might be some maintenance activity going on with Oracle at that time that could be suspending all requests, or at least causing them to run slowly.
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
Am 2013-05-21 20:38, schrieb Mark Thomas: On 21/05/2013 19:01, Michael-O wrote: Mark, I did receive an answer to the issue, citing your findings. See verbatim copy below: Hi Michael, I received the following update from our developer: ** The theoretical problem is that the thread is holding the app class loader so it remains reachable and the app is never unloaded. So if the user loads and unloads the app, the app classes remain in memory. Subsequent loading and unloading of the app will not get pinned in memory as the thread is already running so the subsequent loading and unloading will not cause additional class loaders to be pinned. It is a fixed size memory leak. It does not grow. The thread suggests setting the context class loader to be the parent of the default context class loader. This may work in Tomcat but it's pretty random. I am researching the problem to determine what if anything the driver should do to work across all containers. A Tomcat specific fix is not acceptable. Almost but not quite. The correct fix is to set the context class loader of the Thread to the class loader that loaded the Driver or, alternatively, the class loader that loaded the thread class. As Mark Thomas pointed out it is critical that the driver is loaded in the boot or system or container class loader, not the app class loader. If the driver is in the app class loader then when the app is unloaded the driver also should be unloaded. Unfortunately this doesn't work. The driver itself remains reachable so the app class loader is reachable so the app is never unloaded. At present there is no general way to solve this problem. The necessary hooks are added in JDK 8. I'd agree to this point. Most users put the driver in the container, not the app, so this is rarely a problem. I don't agree with this. I often see this with JDBC drivers which is why Tomcat has a pile of code specifically to unpick the mess this creates. ** I will certainly have to fill out a bug to have it investigated officially. That is good news. Seems like they understood the problem. But I do doubt that this is a fixed size moemory leak. I think the point they are trying to make is that it is only the first instance of the web application to be unloaded that will be pinned in memory. Subsequent reloads won't trigger a leak. That is correct. Mark, here's the next update from Oracle on the issue: 1. For those with Oracle Support access, here's the bug id: 16841748 2. Quote: I don't think any system property is needed. We have a solution for the timeout thread that should work for all app containers. So Oracle is working on a fix, my SR remains open until I receive an updated ojdbc.jar. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Unix daemon (jsvc) - problem with compilation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Kenneth,
On 5/23/13 12:57 PM, Kenneth Erard wrote:
--
We need to use all JAR files from this directory but Tomcat ignore
this syntax (notwithstanding previous version runs correctly) and
it understand only exact JAR definition, for example -classpath
/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-api.jar,/opt/tomcat/lib/tomcat-util.jar,...
Where could be a cause of this problem? Why this version of Tomcat
ignore string -classpath /opt/tomcat/lib?
--
I'm not sure! I'm actually quite new to Tomcat, and don't have an
answer. I previously tried a pattern match (ex:
CLASSPATH=/opt/classes/*.jar or CLASSPATH=/opt/myclasses/*.*)
without success, then switched to loading specific JAR files. Your
problem was exactly what I had experienced with JSVC before I made
the switch -- no classes found. Once I explicitly declared my
JAR files, JSVC was happy.
Perhaps someone with deeper knowledge of Tomcat and JSVC has an
answer.
This has nothing to do with Tomcat, jsvc, or Java at all. Instead, it
is a misunderstanding of how shell wildcard-expansion is done.
If you say export CLASSPATH=lib/*.jar on a *NIX system, you'll get
the CLASSPATH environment variable set to a value like this:
$ export FOO=lib/*.jar
$ echo $FOO
lib/annotations-api.jar lib/catalina-ant.jar lib/catalina-ha.jar
lib/catalina-tribes.jar lib/catalina.jar lib/ecj-4.2.1.jar
lib/el-api.jar lib/jasper-el.jar lib/jasper.jar lib/jsp-api.jar
lib/mysql-connector-java-5.1.24-bin.jar lib/servlet-api.jar
lib/tomcat-api.jar lib/tomcat-coyote.jar lib/tomcat-dbcp.jar
lib/tomcat-i18n-es.jar lib/tomcat-i18n-fr.jar lib/tomcat-i18n-ja.jar
lib/tomcat-jdbc.jar lib/tomcat-util.jar
(If you do set CLASSPATH=lib\*.jar on a win32 system, you'll get
CLASSPATH set to lib\*.jar because on Windows, the shell doesn't do
any expansion: that job is stupidly left up to the individual programs
to handle.)
A proper CLASSPATH variable needs to have the form
resource:resource:resource and not resource resource resource
which is what you have above.
The short answer is that you cannot rely on shell-expansion in order
to collect all JAR files in a directory. Instead, you have to build
the CLASSPATH piece-by-piece, like this:
# Build the classpath to include lib/*.jar
CLASSPATH=
for jar in ${BASE_DIR}/lib/*.jar ; do
CLASSPATH=${CLASSPATH}:$jar
done
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRno+dAAoJEBzwKT+lPKRY1YgP/0vRVudz3R5G4MZmit6OMEMF
uLGYVEiSrXCbLZOyiY8E1cL+j5weWFqTH+WCc1FntUoCL7pCvAGDHDKaVitZvbJl
/UKb1b730T8yOSpq8M3IBCIRHtFvwT9yWkulWj4l5jSb9Oktm/UIlh+iFnWmuB1i
GTx4Q72Ualy40njxCzPCpNjkiobqZiyKGVUK5Sf7OAMHLs39/7FLbz43Rwv5qfB1
II9scX4+LttdfcKduIE4Fvn9fD824th3jC4o9NADGjybkKLYUoa6lXcipnuaWitK
iSoynn/pJYASRX4soWvuaDPNht2YxmKRhlM7dWHyxn0p8YXAcG+6iXqlnXiNiTVU
RtNqi8xetInmjQo8pRC4yINFFHYGJlqhoIXCFfjvoHiaBzsafIb/5WvwA2lQq0jk
iYq0UqMIxr3FAUSlZEhj292u4oLD6W5qbd785pGUvvzD8V+bJJFzrxEf1v37x76D
aoLHG565SAO5VhvGY2S7K+GQ8QbLJdyls5x8QzSn3aTZdRk3vRJuDfr7DlY7IDrC
XrTC15fkTnZomEPUEGt1DRFXPYKj9+/UTh2Bk4qkxetcKCougF6iKCjENPSdZ7oG
AQ+sY7lmXS7F5Q9cl3EE1pbUqMyjnYRT16JYtehQJz8BOKpnQ/mRv1/sTsSp95FT
lEiNb8AhnWslzmLBF71m
=ChqK
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/23/13 1:21 PM, Chirag Dewan wrote: With c=1 it is 70k req/sec and with c=2 it is 35k in both i.e the total req/sec cannot be scaled beyond 70k. With Tomcat 6 it is 60k in both clients i.e total of 120k. I do not expect more than 75k req/sec being served by Tomcat 7,but its the benchmark set by Tomcat 6 which I can't overlook. As I said I wouldn't have mind 80-90 % utilization on peak load,but its the already running server performance which I am compelled to follow or even carry out more. What do you see when you attach a profiler to Tomcat while you run your load tests against it? (Now that you have removed your own webapp from the mix and are just fetching trivial resources). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnpAFAAoJEBzwKT+lPKRY91AQAJicVT7nLNBzr4m7eqOs6sRn R+hCNT37A0HWS8+A8Ns52FyCUUmOljrFVP8LcwA1J0IXFxxI1GvCGNdL7y8248dF cWKyyMYUpmiGbwRBcz0XTvxJoGLwo55Wv7pnYsdecU7d93epXcPSZTQHM3zI82ZB TEShV/AHigcnA9mEe8NV1XgLzCZclh9mjfP2uIhhBHvNkoK3gX0oMey8xK9lezlJ ArGKy1RUNsvnWaDvmFC5o5FQyh8CPDnxXalGgDKnjxFHQfUOtCXaFdWdgeiPL6xn TPiuWIEdqNXERLAjY9IjXzoXpBkxRcYPEwN4V3/tHZapw6C7M9OmcmuXMfhF5UEP G4e+nhcy2CtdUum38j4g1LLEB06QRmc1DIt6czb3kqKQR3FTBpRSkBdWEjJhZnxU JVRIYiK8rOqxXygJcga0VlI5xSIzHh2JK7qlT6rc+zqWQTHXOFkmxyGMfjb+hx+i Mofp0lrO9aczFopb/C3uF7gOAb5c0hhhf1Smxvy9nCl2YscA+BarhWdwiOeEGd+6 mNTK/unQIZLJI3Sqb8xgaaGoa5FEvfoaRptweiqON76hNZGrFDxCnQeG9h6W12uW CGQfEWnbgmWkao/ZrIGYkxmRQNd7n4w2jEfzxdD40yrDX+jyQ7VbWrKkX/m/0K+b 7h8osL0Vaqk+GtaWfuPA =cRWt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 5/23/13 12:01 PM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread Thanks for the pedantry: I was in fact ignoring the difference between the system and boot ClassLoaders. However, the primordial ClassLoader does in fact exist, and does in fact load classes, and is not called the boot ClassLoader. What you're calling the primordial class loader _is_ the boot class loader, identified by a null reference. (The use of primordial in the page you referred to is unusual; it's known as the boot or bootstrap class loader in almost all other documentation.) It's responsible for more than just the java.* packages, since it also loads all the com.sun.*, sun.*, and other JVM-vendor supplied classes. I ignored the extensions class loader, since it's rarely used and was not pertinent to the topic. While I haven't exactly implemented my own JVM or anything like that, I have often heard the boot class loader referred to as the primordial class loader. Either way, we're talking about the same thing. the system class loader is represented by an ExtClassLoader. On top of that is an AppClassLoader. What you're looking at is JVM-internal classes (hence the $ in the names), that just happen to be the ones chosen in current versions of the JVM. The name is an implementation detail; the internal class mechanism is used to handle privilege issues. The internal names should not be construed as descriptive of the class loader hierarchy. I wasn't inferring anything from the names of the ClassLoader objects: just showing what the hierarchy was given the code I wrote. On top of that is an AppClassLoader. Only for programs that supply their own, such as Tomcat. My comments concerned the JVM itself, not Tomcat. Er, I meant that the AppClassLoader (an Oracle-specific thing) was in the hierarchy. The hierarchy I was showing was what actually happens when I run that example class from the command-line, so Tomcat isn't involved. Oracle's JVM has 2 ClassLoader objects between my class and the boot class loader. Presumably one of them is for loading extensions (ExtClassLoader) and then the other (Oracle's AppClassLoader) loads stuff from the CLASSPATH (or -classpath or java.class.path). When placing a JAR file into one of the paths found in java.ext.dirs, the parent ClassLoader for those classes ends up being Oracle's ExtClassLoader -- just underneath the ClassLoader that manages the items on the java.class.path. When I modified java.endorsed.dirs, the classes loaded from those directories were loaded by the primordial/boot class loader. Interesting. I would have expected a layer between them, but I guess it makes sense as you have to be able to override things like org.xml.*, etc. So, at least in Oracle's JVM: java.endorsed.dirs - boot class loader (null) java.ext.dirs - another class loader (ExtClassLoader) java.class.path- a third class loader (AppClassLoader) (In that order: most user classes will start at the bottom and search upwards.) - From within Tomcat, of course, there will be a longer chain from webapp-loaded classes up to the top. DriverManager's ClassLoader is in fact null, the primordial class loader. Unless one configures a replacement DriverManager (I think there's a system property for that, but I'm not sure). +1 ...but who uses DriverManager anymore, anyway? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnpSbAAoJEBzwKT+lPKRYoP0QALrFCAJuCVfCP4BHNLhyGu3F 7YvT1IFS7zSUZlKDf44vOqRfgvQoUdU+Lpj/LTjUxVTEzbvF+5W3LmmQ7Efo3bJd PA1Td2pqGJkUbcO7R1aSF2Xlaqzz9VzKvfjakenBq4MRzBCkzv06eNOoB+tEnyG1 uq+4CB5t4qS1kdEyZAI9wEPLK7wvHJFWZUk8s/NqK/X+rHA1yhzxWjWCOO+EjjZl 0TsQt44aVWhuL8X+goumQRfDkVjI0lpgOnhRQvnZo3b81H9zhhqvOzD9/JucOf+r PwuSRIOLlLloCq1sCSNXgG0YT4lkJsReYmXM8mMjSY8EEa7aTeqZQzLfM1AOLNI4 Wk+fCwHDBxpnBP70oKISVRvEFVgvn4nQIDK9JxVikT/p+QhY6CZU7vSzZMnTDPHP rXaJ2orhp4SIgb1Pr0VZ5RdLn785iEyxzqHVdONik+3XK/1azQ6JKe9TEEXXgVXS AFuuajDm2yJhsYFeYmsKbgAO5L30jxU3/YhgQ0toyYvPi8n11w4J4hjn9gB6WQ2s Rw+3nQ+25Jcww5sZ08nJdu+vcK/tWvjz6/B/vGrkpAilRZs5xxKAmwb4V+G5NiBs Fr3ph5Ys5kV03axHZRRxhjxqfF/GZdeAVHDc57//Vd0S9zuyZ1CWmXVqAJXfrnil fafc/jc6sAnd865xQ23X =w6CF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread While I haven't exactly implemented my own JVM or anything like that, I have... I have often heard the boot class loader referred to as the primordial class loader. Both the JVM and Java Language specs refer to it as the bootstrap class loader: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.3.1 The word primordial does not appear anywhere in the JVM spec, and only as a descriptive term for the Object class in the language spec. So, at least in Oracle's JVM: Also in any JVM serious about running Java programs. java.endorsed.dirs - boot class loader (null) The boot[strap] class loader, as noted. java.ext.dirs - another class loader (ExtClassLoader) The extensions class loader, rarely used. java.class.path- a third class loader (AppClassLoader) The system class loader, officially (java.lang.ClassLoader.getSystemClassLoader()). Interestingly enough, the above hierarchy does not appear in any spec I can find, although you'd be hard pressed to find a JVM that doesn't implement it that way. Using AppClassLoader as the internal name for the system class loader is unfortunate, since it creates confusion with common usage and an actual Application Class Loader, as described in this link: http://docs.oracle.com/cd/E19501-01/819-3659/beadf/index.html That one does seem like a bit of overkill... - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Unix daemon (jsvc) - problem with compilation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jaroslav, On 5/23/13 4:37 AM, Jaroslav Fikker wrote: Hello everybody. I encountered a problem with compilation of Unix daemon (jsvc) against IBM Java from Tomcat 7.0.40. I used these commands: cd /opt/tomcat/bin tar xvfz commons-daemon-native.tar.gz cd commons-daemon-1.0.x-native-src/unix /configure and I got this output: *** Current host *** checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking cached host system type... ok *** C-Language compilation tools *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for ranlib... ranlib checking for strip... strip *** Host support *** checking C flags dependant on host system type... ok *** Java compilation tools *** checking for JDK os include directory... Cannot find jni_md.h in /usr/lib/jvm/java-1.6.0-ibm.x86_64/ configure: error: You should retry --with-os-type=SUBDIR I found information that the reason is: IBM java uses $JAVA_HOME/include/jniport.h instead of $JAVA_HOME/include/jni_md.h in Oracle java. When I created a link jni_md.h to jniport.h I can successfully compile jsvc but when I try to start Tomcat server I have a problem with class loading (Java class not found). Is there some fix or recommendation for compilation Tomcat Unix daemon with IBM Java? Thank you very much for your help. As for the configure script, it seems like it is a bug to look for jni_md.h, as it's not an official part of JNI. configure seems to go through great pains to determine the value of JAVA_OS (which is the platform-specific subdirectory for header files) and then completely ignores the value of JAVA_OS. Honestly, I think it should probably be removed, but I'd like to hear a comment from someone more well-versed in jsvc. If you are having a problem with actually running jscv, please start a new thread with a new subject for a separate question. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRntT9AAoJEBzwKT+lPKRYyekP/R25iMv3+w/WAWgaaimdESY2 0bppTnI/WYLPBR9NJC0HkAGV1dk2rGVixiBNmE9xg7GrghizwOTikgw7BPuFgbCY k3D7Uumt6xD9kt28lbPMO8JD8X+28dutu3Y6IUzIj2DV5AMPLuyBwqzaoho/84at KNBEJqU3hHuFRxRpdnIEMlwlr3G2Cvrz72JNTWl6iMhX8ge2w40M8bhGKAp4lL0w dW1pBpAsCb7LmbVBwCq78iGOeZaO4/ktRbrV5B5cCMj1WwWymUMzP0ZykO+Qbuuj 7074KnqhEFhp9Tn91zSy6WYWYzpKCgNeQcwk21IQrZY6UuxCfOhs5zNuBChwD/HA 3tNTs4Ld1wJrTPP2dGKiZNBcSVAapjoVKEm5e0Rd1Xp6BAwXvnAUjnbq36BN1hbq xAO3UNMgnYCvCEGj2edYnqGhv0n2vHDQw+mBxsHP/znJ+X56388epEJDHqCqVm59 j916mQuI7q5vMoCLQZo3RjKCePu50M3A4IrSjkauctHmKX7p4bvgFNd1smDxKaQb FUBi3upZH6vzT0xzN6YGal9UPcfQhO+X4qPzrWJ866448cA0+Z+tKTNct6JTlRWP qdXEwICJYoyVnSPlUqEcl99n+OWPYa/Rmsci0NCXEzxIz5PE5p8BQDFeLAWtAKdm 7rpPfkJGghj46oj6NqTj =X9/h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7
Chris, The profiler shows very high CPU utilization in Tomcat threads. As I said before a lot of time was spent during the ResponseFacade.setContentType() method call. That doesn't tell the whole story but more or less the high utilization is mainly in the tomcat threads. The thing which puzzles me the most is I am able to scale the req/sec with multiple clients on Tomcat 6 and the same doesn't happen on Tomcat 7? Can it be the JVM? Would it help trying with a latter version of JVM? Thanks. From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Friday, 24 May 2013 3:24 AM Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chirag, On 5/23/13 1:21 PM, Chirag Dewan wrote: With c=1 it is 70k req/sec and with c=2 it is 35k in both i.e the total req/sec cannot be scaled beyond 70k. With Tomcat 6 it is 60k in both clients i.e total of 120k. I do not expect more than 75k req/sec being served by Tomcat 7,but its the benchmark set by Tomcat 6 which I can't overlook. As I said I wouldn't have mind 80-90 % utilization on peak load,but its the already running server performance which I am compelled to follow or even carry out more. What do you see when you attach a profiler to Tomcat while you run your load tests against it? (Now that you have removed your own webapp from the mix and are just fetching trivial resources). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRnpAFAAoJEBzwKT+lPKRY91AQAJicVT7nLNBzr4m7eqOs6sRn R+hCNT37A0HWS8+A8Ns52FyCUUmOljrFVP8LcwA1J0IXFxxI1GvCGNdL7y8248dF cWKyyMYUpmiGbwRBcz0XTvxJoGLwo55Wv7pnYsdecU7d93epXcPSZTQHM3zI82ZB TEShV/AHigcnA9mEe8NV1XgLzCZclh9mjfP2uIhhBHvNkoK3gX0oMey8xK9lezlJ ArGKy1RUNsvnWaDvmFC5o5FQyh8CPDnxXalGgDKnjxFHQfUOtCXaFdWdgeiPL6xn TPiuWIEdqNXERLAjY9IjXzoXpBkxRcYPEwN4V3/tHZapw6C7M9OmcmuXMfhF5UEP G4e+nhcy2CtdUum38j4g1LLEB06QRmc1DIt6czb3kqKQR3FTBpRSkBdWEjJhZnxU JVRIYiK8rOqxXygJcga0VlI5xSIzHh2JK7qlT6rc+zqWQTHXOFkmxyGMfjb+hx+i Mofp0lrO9aczFopb/C3uF7gOAb5c0hhhf1Smxvy9nCl2YscA+BarhWdwiOeEGd+6 mNTK/unQIZLJI3Sqb8xgaaGoa5FEvfoaRptweiqON76hNZGrFDxCnQeG9h6W12uW CGQfEWnbgmWkao/ZrIGYkxmRQNd7n4w2jEfzxdD40yrDX+jyQ7VbWrKkX/m/0K+b 7h8osL0Vaqk+GtaWfuPA =cRWt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
