I have been pulling my hair out for days on this one.
I have a swing app (maybe that's the problem ) that searches recursively for files. For each file it lists the name in the gui, as well as a few other things for this file. So I initially kick off a SwingWorkerThread to let that process in the background. The SwingWorkerThread is a simple thread that just loops over all the files in a directory (first time it uses the starting directory) and for each directory it starts up another thread the will get all the file names from that directory and put them in the GUI. I did this so that searches would be very fast as with each new directory a thread would get kicked off to 'process' the files in that directory.
The problem is I need the user to be able to cancel the search. However when I call shutdownNow on the thread pool the threads do not shut down right away. I.E. I guess my threads are not getting interrupted. So if I have a directory with 10,000 files and the user hits cancel the thread keeps adding these files to the gui because the thread pool is not really shutting down the threads.
Has anyone run into this problem before? Why is the executor not interrupting my threads? Does it have to due with the type of queue I am using for my thread pool? Do I need to check somewhere in my runnable code if I have been interrupted (not sure how though I thought the code just gets interrupted).
Yeah, you have to make your code respond to interruption. One easy way is to periodically check the Thread.isInterrupted() flag, and if true stop processing.
Joined: Aug 04, 2009
And hope you are using a FixedThreadPool to limit the maximum threads to something decent. Else creating a thread for each directory can lead to thousands of threads that run together and your application will bring the system to its knees including strangling itself for CPU.