1

I have an application which uses a third party jar to do some task. My application uses Spring Executor pool to spawn the threads.

Question: I need to stop the current execution of a thread if the executing time exceeds the time limit

What I did: I googled a lot about interrupting thread. Most of says to check the interrupt flag whether the thread is interrupted or not and if interrupted throw an interrupted exception. But in thread I'm calling a method which is in a third party jar which do most of the stuffs so I can't go there and change the code for checking the interrupt flag.

Consider the following code snippet:

public void run() {
     boolean isDone = false;
     isDone = callThirdPartyMethod(); // here for some inputs thread takes more time (even never return for an hour!!) to process which I don't want and I need to stop/interrupt the thread
}

Approaches I follow for stopping/interrupting it

  1. I had wrote a TimerTask which checks for the thread which is exceeding the time limit and call the interrupt() on them (but it seems nothing happens as they continue their execution).
  2. I changed the code of my TimerTask from interrupting it to calling the stop() on thread. This works but it throws ThreadDeath error. Also what I read in most of the blogs and even in stackoverflow is that we should never call the stop method.
dnup1092
  • 375
  • 4
  • 15
  • A well designed 3rd party library should handle interruption signal properly. Maybe you should consider selecting another library. – waltersu Aug 08 '16 at 01:58
  • You can try this approach: http://stackoverflow.com/questions/6859681/better-way-to-signal-other-thread-to-stop – apruden Aug 08 '16 at 02:04
  • @waltersu can't change the library. – dnup1092 Aug 08 '16 at 02:07
  • @apruden that approach is not working for me – dnup1092 Aug 08 '16 at 02:10
  • why is it not working? is the third party library catching the interrupt signal? – apruden Aug 08 '16 at 02:13
  • 1
    Calling thread.stop is a bad idea. It might work ok- or it might corrupt data structures to the point that all future requests return incorrect data. That's why the function is deprecated- because a thread can't be safely stopped by an outside source. Unless you plan on immediately rebooting the app, never trust stop. – Gabe Sechan Aug 08 '16 at 02:18
  • @dnup1092 If you can't change the library, is it open source? Maybe you could submit a patch so that it respects the interrupt signal? – Maybe_Factor Aug 08 '16 at 02:18
  • @Maybe_Factor no it is not open sourced and this is the main drawback otherwise I would have given a patch. – dnup1092 Aug 08 '16 at 02:34
  • @Gabe Sechan . Yes you are correct I actually corrupts the data structures through I have given a thought to stop but not actually going to use it and I'm finding the alternative – dnup1092 Aug 08 '16 at 02:36
  • @apruden when I called the interrupt() nothing happened. The thread continues the executions. As it is not preemptive the lib should poll the interrupted flag and should throws the exception but it is not happening which ideally should happen – dnup1092 Aug 08 '16 at 02:38
  • Stop might still be the solution. You are explicitly stopping the thread, so it's likely that you can identify and discard any state that might have been modified by that thread. The main issue with "damaged" objects is that multiple operations that were intended to appear atomic through locking are only partially completed. For example, if you were using an STM system (software transactional memory), stopping a thread would be no problem. Perhaps you can use a similar principle in your application. – erickson Aug 10 '16 at 18:33

1 Answers1

2

Question: I need to stop the current execution of a thread if the executing time exceeds the time limit

There is no easy answer here. Typically you create one thread to make the third party library call and one thread to watch the clock and kill the other thread when a timer expires.

You can call interrupt the third party library thread but as you mention there is no guarantee that callThirdPartyMethod() will listen for the interrupt. You can call stop() but this is deprecated for good reasons.

The only addition mechanism is to close something that the third party library is using. Maybe a socket or other connection could be closes out from under the library.

If there is not way to do it then thread.stop() is your only (unfortunate) alternative unless you can get at the source of the library.

Otherwise you are SOL unfortunately.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • I am using Java 7 so can't fork I guess, as this is added in Java 8(correct me if I'm wrong). My main concern is about thread stopping or interrupting. I have managed to write a timer. Even I think there is no way other than to use stop(). – dnup1092 Aug 09 '16 at 00:45
  • Sorry @dnup1092, I meant fork as in create. I've changed my answer. I think you are right about `stop()`. Just read the docs about why it is bad and maybe it doesn't affect you. – Gray Aug 10 '16 at 15:33
  • 1
    `finally` blocks are not violated by `Thread.stop()`. The concern about damaged objects being unlocked for other threads to access inconsistent state is a bit overhyped, I believe. Any `RuntimeException` can have the same effect. – erickson Aug 10 '16 at 15:44
  • @Gray no problem pal. I checked by using stop() and it causes my sessions to break. I think there is no way out. And I think JCP can have a look into this scenario. – dnup1092 Aug 10 '16 at 16:45