Automatically detect dangling streams
I am currently looking for a way to identify dangling threads in java. Does anyone know what is the best way to do this?
Currently I could think of two possible ways to do this:
- Call the method (callback) periodically in all methods of the application. It seems "a little" complicated and unsightly ... Moreover, I have no control over external calls ...
- An additional thread that periodically generates Thread-dumps for all threads (or perhaps only a few that need to be monitored) since I know which thread I want to monitor) and parses the result ("this thread is still at the same point with locks on the same facilities ", ...). This can be a little dangerous as the Thread can be at the same point again (!) ... By the way, is there an easy way to get a thread dump in Java 1.4 (I don't want to call an external application). I think as of 1.5 or 1.6 there are ways to easily do this ...
I think these two methods are not a good solution ... Do you know how to do it?
As I said, I don't want to use external applications ...
I found that when we have threads stuck, we usually face a performance issue on our application server.
We have a low-tech way to identify where threads are stuck.
We send multiple kill -3 JULs to generate multiple thread dumps, and then analyze the output, looking for similar traces, pointing out the problem code.
Low tech and manual, but it worked.
a source to share
If you are looking for an "automatic" way. There is no good solution other than spending more time in the design process. If you have threads that are hanging, then they were not closed properly. I would spend time on how to contextually close them, rather than trying to write a routine / thread that looks for stale threads.
a source to share
This is just an idea:
Store in centralized (synchronized) information about the start time of the stream and links to the stream. In the example ConcurrentHashMap (now CHM).
It's been some (conservative) time when you can ask the CHM for this thread (or whatever thread you suspect can be hung) to start it. If the thread is still alive, you can (conservatively) make sure it hangs.
You can go ahead and keep the stacktrace of threads as commented earlier.
a source to share
The question here is what "thread hang" means and in what context.
Is it inside a large J2EE server (which can probably find itself) or a tiny Java program where you create many threads? If it's the latter, consider using Parallel Utilities in Java 5+, which allows you to manage Runnables and Callables.
a source to share
If you have a race condition, then casting additional resources (i.e. installing the JDK and using jps and jstack) to solve the problem is definitely smart ...
However, if you are using the application outside of the container, you can simply launch the application from the console and press ctrl + break (Windows) to get a thread dump. Or kill -3 on * nix.
But based on your answers in the comments, it looks like this is probably working on some kind of application server.
The problem here is that pretty much everything you do has to introduce additional uncertainty into the situation. How do you know if your deadlock monitor itself is not responsible for locks?
Another option is to introduce a log of system logins and then create a replay of what happened in the system based on those logins. If your client basically said they won't help you fix your race condition, then you need to find it yourself in your own test environment. Emulating load conditions on a client site is one way to do this.
But actually I recommend you work with them to install a JDK (for example you can use jstack) or a JRE 1.4 monitoring app (heck, make sure their app server hasn't provided this kind of thing yet).
a source to share