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/' | sortOnce 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.