0

I have created an automated test suite which has a thread pool running simultaneously in the background of all test cases in order to obtain given system and performance metrics. Each thread is using a JSch connection to execute its shell commands and they are receiving [JSchException: Channel not opened exceptions].

The key problem is that the test suite continues to run forever, because the threads are not exiting even when all test cases have ended. But I'm not sure why...

When I checked the thread dump, I found that the threads do not exit because they are in a BLOCKED status.

Does anybody have an explanation for this? Or some help in resolving this issue?

tmcevoy
  • 1
  • 1
  • 1
    can you post the tested code ? – Wagner Michael Jan 26 '15 at 17:08
  • 1
    The threads are probably just waiting to receive further work. You must end your testing session with an explicit shutdown of all subsystems you explicitly started. – Marko Topolnik Jan 26 '15 at 17:08
  • See [Mutex lock: what does "blocking" mean?](http://stackoverflow.com/questions/3982501/mutex-lock-what-does-blocking-mean). It sounds like your threads are contending for a resource... – gknicker Jan 26 '15 at 17:24
  • I am already shutting down the pool after each method: @AfterMethod(alwaysRun = true) public final void afterMethod(final ITestResult result) { if (pool != null) { pool.shutdownNow(); } } – tmcevoy Jan 26 '15 at 17:31

1 Answers1

0

I guess you mean the shutdownNow() method of ExecutorService. This is the documentation (I formatted the relevant parts in bold):

Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution.

This method does not wait for actively executing tasks to terminate. Use awaitTermination to do that.

There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. For example, typical implementations will cancel via Thread.interrupt(), so any task that fails to respond to interrupts may never terminate.

Thread interruption is a cooperative process, your threads must be implemented so that they respond to interruption.

EDIT

1) About Thread.currentThread.interrupt() see this question: Why invoke Thread.currentThread.interrupt() when catch any InterruptException?

So you need to do this only if you have other methods/thread groups watching the interrupted status. In your case, probably not, but it does not hurt.

2) It seems that in "ShellUtils.executeCommand" you are running external programs. This could be the source of the problem if this method does not react to thread interruptions.

Community
  • 1
  • 1
lbalazscs
  • 17,474
  • 7
  • 42
  • 50
  • I am currently catching an InterruptedException in each of my threads and then breaking from the thread loop. Is this not enough to respond to the interruption? Or do I need to add a Thread.currentThread.interrupt() to the catching condition? – tmcevoy Jan 27 '15 at 11:29
  • I.e while (true) { try { final String output = ShellUtils.executeCommand(hostname, COMMANDS).getStdOut(); final String[] measurements = output.split(Constants.RegularExpressions.NEWLINE); if (measurements.length == METRICS.length) { writeMetricData(measurements); } else { Logger.log(Level.SEVERE, "failed to execute one or more commands"); } Thread.sleep(SLEEP_TIME); } catch (InterruptedException e) { break; } – tmcevoy Jan 27 '15 at 11:30