|
Killing an Ill-behaved Thread
I am working on a problem wherein my code is calling to a hardware device driver (written in Java and native code) and the thread is freezing. This in turn causes my application to freeze solid, requiring us to kill the JVM and restart it. To make a long story short, this is a support nightmare and one we would rather work around if possible.
The flow looks something like this:
1. Application controller thread receives a request to perform an action: this involves hardware interaction.
2. Our hardware framework spawns a thread to service the request.
3. The thread calls into a proprietary, closed-source driver for which we have no source code and cannot make any changes.
4. Said driver can, under specific circumstances, reach a point where it freezes. This causes our thread to freeze, which in turn will cascade up and cause the application to freeze. This is not technically deadlock but has similar characteristics. Removing this deadlock is what I am trying to do, but changing an application framework is not something to do lightly.
So far we have not been able to fix this. Part of the problem is design on our part, the system architecture is fairly robust but in some cases is very susceptible to threading problems. The second half of the problem is Java's lack of a "kill no matter what" mechanism for threads.
The driver itself traps all exceptions and all method calls that might stop it. It simply catches whatever we throw at it and continues waiting: for what we do not know.
Is there maybe a special Executor implementation that could do this? Maybe one that is written in native code, bypassing the (weak) Java kill mechanisms? I know the contract of Executor is that it provides additional thread management capabilities, is there any implementation that can do this?
While we have a support ticket open with the hardware vendor, this is not the first time this issue has come up. If I can find a way to kill such a thread then I will change our framework to handle this more gracefully. Neither myself nor my team's resident hardware guru are aware of any way to do this.
|