G's Blog

I was looking at a bit of code was leaking class loaders when deployed to tomcat - so I wanted to quick rule out that a background Thread was holding onto the loader. Pain by eye, it is quite easy with a few unix commands to process the stack trace, filter for the lines that contain the thread name, filter for just the thread names and sort:

sudo -u tomcat jstack 1853 | grep " prio=" | sed -e 's/"\(.*\)".*/\1/' | sort

Once this is done it is a simple matter to pipe the output to a file, say /tmp/before.threads, then run the deploy task a small prime number of times in order to create a clear signal, and then compare with the original thread list

[gdavison ~]$ diff /tmp/before.threads /tmp/after.threads
26a27
> RMI TCP Connection(11)-127.0.0.1
[gdavison ~]$

As with any server there will be a lot going on, in this case I saw a spurious RMI thread we can probably ignore, but if there was any application specific thread leakage the problem should repeat a number of times that is cleanly divisible with the prime number you picked before, for example where the prime is three with an example issue:

[gdavison@slc01htu ~]$ diff /tmp/before.threads /tmp/after.threads
8a9,11
> Problem Thread
> Problem Thread
> Problem Thread
26a30
> RMI TCP Connection(11)-127.0.0.1
[gdavison ~]$

As I say quick and dirty; but might be worth writing down for later use.