Forceful termination of a thread stuck on an API call of some method

Question

My scenario is as follows:

I am implementing a server that must timeout or produce a response within the specified timeout period for each request. Thus each request is ensured a response from the server's point of view (the response, of course, might not reach the client due to transport layer failure, etc...).

In order to implement the above semantics, each request spawns a thread (actually retrieves an available one from a thread pool) and awaits its response via a notify on a sync object. The wait period is limited with a timeout param sent to Object's wait method. The spawned thread delegates the request to an object that actually knows how to handle the request. This object's call API is known, but there is no known service level agreement which would specify that a call will never hang indefinitely. (Specifically in my case, the Server is actually a CORBA client - but that is not the point.)

Now, what interests me, is whether or not there is a way for me to somehow detect that that thread is not responsive and then kill it (interrupt it) even though I am currently blocked on a method call?

By the way, I know that I can keep a reference to the thread object and after a pre-specified amount of time call its interrupt() method. That unfortunately does not ensure "interrupt" semantics...

Java Thread Primitive Deprecation

Thanks all

Answer 1

Try using an ExecutorService and make the actual business logic be performed in a Callable. The Future returned by the ExecutorService has a get() that allows you to specify how long you will wait...

Answer 2

I think if you can't rely on interrupt() semantics then you may be out of luck. There is no reliable or safe way to forcefully terminate a thread. It's dangerous in any language.

I would hope that interrupt() would get you what you need even if it could be circumvented. The CORBA calls should be going through the standard network classes and therefore should properly interrupt on any blocking calls.

It's the best you can do short of spawning full child processes.