Getting a thread-dump is one of the first steps in troubleshooting a misbehaving Java application. There are a few good ways todo this task but the easiest of them all is
kill -3 <PID>
This will send the thread-dump to your stdout logs.
10 Nov
Getting a thread-dump is one of the first steps in troubleshooting a misbehaving Java application. There are a few good ways todo this task but the easiest of them all is
This will send the thread-dump to your stdout logs.
2 Sep
[root ~]# cd $TOMCAT_HOME/bin && tar -zxf jsvc.tar.gz [root ~]# cd jsvc-src && chmod +x configure [root ~]# ./configure [root ~]# make
Now there whould be a file called jsvc in $TOMCAT_HOME/bin/jsvc-src/native/ please move this file to $TOMCAT_HOME/bin/jsvc this is the Java service executable that will execute your Tomcat server. The next step is to setup your init file, lets create the file /etc/init.d/tomcat that will be used to start Tomcat with jsvc.
#!/bin/sh ############################################################## # chkconfig: 345 98 98 ### BEGIN INIT INFO # Provides: Tomcat # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop Tomcat # Description: Tomcat is a J2EE Application server ### END INIT INFO CATALINA_HOME=/usr/local/tomcat DAEMON_HOME=/usr/local/tomcat TOMCAT_USER=tomcat # Make sure we load the setenv.sh file # since we don't use the startup.sh script . $CATALINA_HOME/bin/setenv.sh # for multi instances adapt these lines. TMP_DIR=/var/tmp PID_FILE=/var/run/jsvc.pid CATALINA_BASE=/usr/local/tomcat CLASSPATH=\ $JAVA_HOME/lib/tools.jar:\ $CATALINA_HOME/bin/commons-daemon.jar:\ $CATALINA_HOME/bin/bootstrap.jar case "$1" in start) # # Start Tomcat # #-user $TOMCAT_USER \ echo $"Starting Tomcat..." cd $CATALINA_HOME && \ $DAEMON_HOME/bin/jsvc \ -home $JAVA_HOME \ -Dcatalina.home=$CATALINA_HOME \ -Dcatalina.base=$CATALINA_BASE \ -Djava.io.tmpdir=$TMP_DIR \ -wait 10 \ -pidfile $PID_FILE \ -outfile $CATALINA_HOME/logs/catalina.out \ -errfile '&1' \ $CATALINA_OPTS \ -cp $CLASSPATH \ org.apache.catalina.startup.Bootstrap # # To get a verbose JVM #-verbose \ # To get a debug of jsvc. #-debug \ exit $? ;; stop) # # Stop Tomcat # echo $"Stoping Tomcat..." $DAEMON_HOME/bin/jsvc \ -stop \ -pidfile $PID_FILE \ org.apache.catalina.startup.Bootstrap exit $? ;; restart) $0 stop $0 start exit $? ;; *) echo "Usage: tomcat {start|stop}" exit 1;; esac
Now you can start tomcat using /etc/init.d/tomcat start. You will see TWO java processes running on your computer when Tomcat is started in this way. There is one control process and then there is the wrapper for your java process (Tomcat).
24 Aug
I recommend using the default 8080 and 8009 first if you are planning on none-default port install. When you have 8080 (telent) and 8009 (IIS7) working you can change the ports.
Thanks to http://jspors.blogspot.com/
14 Jul
Where do I put the “Enable verbose GC” setting in Tomcat? Is there a switch or something?
The file that you should use to enable verbose gc for Tomcat ( Or for the JVM that Tomcat is running in ) is $TOMCAT_HOME/bin/setenv.sh/.bat. This file might not exist in your install so when you create the file it will be loaded from the $TOMCAT_HOME/bin/catalina.sh/.bat script. Here is the snip from around line 110 in catalina.sh
if [ -r "$CATALINA_BASE"/bin/setenv.sh ]; then . "$CATALINA_BASE"/bin/setenv.sh elif [ -r "$CATALINA_HOME"/bin/setenv.sh ]; then . "$CATALINA_HOME"/bin/setenv.sh fi
Here is an example setenv.sh file with verbose gc enabled, look at the bold part:
JAVA_OPTS="-Xms256m -Xmx512m \ -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -verbose:gc -Xloggc:/tmp/gc.log" CATALINA_OPTS="-Dappserver.home=$CATALINA_HOME \ -Djava.library.path=/usr/local/apr/lib \ -Djava.awt.headless=true \ -Dcom.sun.management.jmxremote \ -Dcom.sun.management.jmxremote.port=8050 \ -Dcom.sun.management.jmxremote.ssl=false \ -Dcom.sun.management.jmxremote.authenticate=false" export JAVA_OPTS CATALINA_OPTS
Now restart tomcat and you are done!
29 Jun
After a good amount of research and issues that looked like memory leaks I’m moving my jvms to 32-bits JVMs for the servers that do not need a heap larger than 2GB. This was ok and a fast switch of the /usr/local/java symlink, BUT it was not as easy with JSVC that I use to run Tomcat under the user tomcat. The problem is that when I compile jsvc on a 64-bits machine it will auto-magically find the box as x86_64 and then expect that your jvm is also 64 bits.
What I found that needs to be done is to force the compiler to use 32bit flags, so first lets run the configure string
[root ~]# cd /usr/local/tomcat/bin && tar -zxf jsvc.tar.gz [root ~]# cd jsvc-src && chmod +x configure [root ~]# CFLAGS=-m32 CPPFLAGS=-m32 CCASFLAGS=-m32 LDFLAGS="-L/usr/lib -L/lib" ./configure --build=i686-pc-linux-gnu
now the next step is to run make
[root ~]# make
What you will now see is that the last step of the make will fail horribly with the following error:
gcc -L/usr/lib -L/lib -ldl -lpthread jsvc-unix.o libservice.a -o ../jsvc /usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libdl.a when searching for -ldl /usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/bin/ld: warning: i386 architecture of input file `jsvc-unix.o' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(arguments.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(debug.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(help.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(home.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(java.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(location.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(replace.o)' is incompatible with i386:x86-64 output /usr/bin/ld: warning: i386 architecture of input file `libservice.a(dso-dlfcn.o)' is incompatible with i386:x86-64 output make[1]: Leaving directory `/usr/local/tomcat/bin/jsvc-src/native'
Looks like the last gcc left out the -m32 and therefor fails.. Lets do the last task manually
[root ~]# cd native && gcc -m32 -L/usr/local/java/lib -L/usr/lib -L/lib -ldl -lpthread jsvc-unix.o libservice.a -o ../jsvc && cd ..
now if you do the following you should have a correctly compiled 32-bits jsvc executable that points to your 32 bits jvm
[root ~]# file jsvc jsvc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
Nice!
http://www.mail-archive.com/users@tomcat.apache.org/msg36176.html
29 Apr
By using swallowOutput="true" and configuring a default context we will send all logging to the default log that we have timestamp rolling enabled for.
Engine
Logger className="org.apache.catalina.logger.FileLogger" prefix="catalina_log." suffix=".txt" timestamp="true"Host
Logger className="org.apache.catalina.logger.FileLogger" directory="logs" prefix="localhost_log." suffix=".txt" timestamp="true" DefaultContext reloadable="false" crossContext="true" swallowOutput="true"
Recent Comments