8

What are some workarounds when dealing with third party libraries that don't correctly clean-up threads when the library is shutdown?

Many libraries expose lifecycle methods, either explicitly or implicitly, for the code contained therein. For example, a web application framework exists within a web application context in a servlet container. When the context is created, the framework may start some threads, for various reasons.

Now, taking the example further, when the servlet container or the web application context is shutdown, the web application framework should terminate all these threads. Either the ExecutorServices created by the library should be shutdown, or some other means of stopping those threads should be enacted.

Worst case is that the threads are non-daemon threads. These would actually stop the termination of the Java process. But even if they are daemon threads, allowing threads to continue is probably bad practice. If (back to the example) the servlet container is embedded within other code that other code may continue to run with the threads still chugging away, which may cause problems.

There's no programmatic way exposed to stop these threads, so what can be done?

If you are using such a third party library, what are the ways to force existing threads to be shutdown?

Community
  • 1
  • 1
Dan Gravell
  • 7,855
  • 7
  • 41
  • 64

1 Answers1

5

If you are using such a third party library, what are the ways to force existing threads to be shutdown?

In general, there is no safe way to do this that is guaranteed to work in all cases. The closest you are likely to get to a safe solution is to use the ThreadGroup to enumerate all existing Threads, and use Thread.interrupt() to tell each thread to go stop. Of course, there is no guarantee that the threads will pay attention, or that they will shutdown cleanly in response to an interrupt.

IMO, the best strategy is:

  • if the threads do not need to be shut down cleanly, then pull the plug on the JVM by calling System.exit()

  • if the threads need to be shut down cleanly to avoid the possibility of damage, then don't use the library ... or fix the problem yourself.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 3
    +1 You can run the library is a separate process which reduces the impact of killing the process. (Works for JNI libraries as well) – Peter Lawrey Aug 10 '12 at 13:18
  • Thanks @Stephen . Yes, all threads can be retrieved, and their ThreadGroups, as described here: http://stackoverflow.com/questions/1323408/get-a-list-of-all-threads-currently-running-in-java . System.exit() only works when the library that was creating the threads is considered the 'first class' code for that process. It's no good if the library is simply *used by* the code. – Dan Gravell Aug 10 '12 at 13:20
  • 1
    @Peter depends on the library of course... running in a separate process will make communication more difficult. – Dan Gravell Aug 10 '12 at 13:22
  • @DanGravell It depends on whether killing everything to bring down the library is acceptable or not. – Peter Lawrey Aug 10 '12 at 13:24
  • @DanGravell - I mean that the application should call `System.exit()`. The 3rd party library can't be relied on to do anything. I don't understand your point about "first class" libraries. – Stephen C Aug 10 '12 at 13:25
  • @Stephen I agree, it's just that the application may want to continue running, and the library isn't required anymore. Consider an OSGi container (this is what first prompted my question). In OSGi, when a bundle exits its Activator.stop() method all threads created by the bundle *must* have been stopped. – Dan Gravell Aug 10 '12 at 13:27
  • @DanGravell - as I said in the first sentence of my answer - *"there is no safe way to do this that is guaranteed to work in all cases"*. If the library misbehaves, look for an alternative library ... or fix it yourself. – Stephen C Aug 10 '12 at 13:29
  • @Stephen Sure, and that's what clinched the answer tick (to be clear: I don't necessarily expect a catch all answer - as you said the way that thread interruption works precludes that). – Dan Gravell Aug 10 '12 at 13:31
  • just curious... does Microsoft's CLR handle this similarly? – Jason S Feb 09 '17 at 17:23