CODEWITHSUNDEEP
javamultithreading
dma_k
dma_k

Reputation: 10639

Terminate a thread which is running a native code

In my application I have a wrapper over some native code, which is called via JNI bridge. This native code needs to be executed in separate thread (parallel processing). However the problem is that the code sometimes "hangs" so the thread needs to be terminated "by force". Unfortunately I haven't found any "delicate" method to do so: general advise is to tell the code in a thread to exit gracefully, but I can't do it with this native code (which is 3rd party code all above).

I use Java Concurrent API for task submission:

Future<Integer> processFuture = taskExecutor.submit(callable);

try {
    result = processFuture.get(this.executionTimeout, TimeUnit.SECONDS).intValue();
}
catch (TimeoutException e) {
    // How to kill the thread here?
    throw new ExecutionTimeoutException("Execution timed out (max " + this.executionTimeout / 60 + "min)");
}
catch (...) {
    ... exception handling for other cases
}

Future#cancel() will only interrupt the thread, but it will not terminate it. So I used the following trick:

class DestroyableCallable implements Callable<Integer> {

    private Thread  workerThread;

    @Override
    public Integer call() {
        workerThread = Thread.currentThread();

        return Integer.valueOf(JniBridge.process(...));
    }

    public void stopWorkerThread() {
        if (workerThread != null) {
            workerThread.stop();
        }
    }
}

DestroyableCallable callable = new DestroyableCallable();

Future<Integer> processFuture = taskExecutor.submit(callable);

try {
    result = processFuture.get(this.executionTimeout, TimeUnit.SECONDS).intValue();
}
catch (TimeoutException e) {
    processFuture.cancel(true);
    // Dirty:
    callable.stopWorkerThread();

    ThreadPoolTaskExecutor threadPoolTaskExecutor = (ThreadPoolTaskExecutor) taskExecutor;

    logger.debug("poolSize: " + threadPoolTaskExecutor.getPoolSize() + ", maxPoolSize:"
                    + threadPoolTaskExecutor.getMaxPoolSize() + ", activeCount:"
                    + threadPoolTaskExecutor.getActiveCount());
    }

    throw new ...;
}
catch (...) {
    ... exception handling for other cases
}

The questions/problems with this code:

Notes:

Bounty edit: The approach/suggestion to revisit the native code is clear, please do not offer it in your reply. I need pure-Java solution / workaround.

Upvotes: 9

Views: 8837

Answers (5)

Tudor
Tudor

Reputation: 62439

Definitely an ugly hack you have here...

First of all, thread pool threads are not meant to be tempered with individually and should generally be left to run until completion, especially not stopped with Thread.stop() which is not recommended even for normal threads.

The use of Thread.stop(), as I've said, is never encouraged and generally leaves the thread in an inconsistent state, which is probably the cause for the thread pool not seeing the thread as "dead". It might not even kill it at all.

Any idea why the native code hangs? I think the root of your problem is here, not the thread stopping part. Threads should normally run until completion whenever possible. Perhaps you can find a better implementation that works correctly (or implement something different if you wrote it).

Edit: As for point 3, it's probable that you need to declare the reference to the current thread as volatile since you are assigning it in one thread and reading it in another:

private volatile Thread workerThread;

Edit 2: I'm starting to get the idea that your JNI code only does numeric computations and does not open any handles that may remain in an inconsistent state should the thread get abruptly killed. Can you confirm this?

In that case, allow me to go against my own advice and tell you that in this case you may safely kill the thread with Thread.stop(). However, I do recommend you to use a separate thread instead of a thread pool thread in order to avoid leaving the thread pool in an inconsistent state (as you've mentioned, it does not see the thread as dead). It's also more practical, because you don't have to do all those tricks to get the thread to stop itself, because you can just call stop() directly on it from the main thread, unlike with thread pool threads.

Upvotes: 2

BegemoT
BegemoT

Reputation: 3856

Java has pure options for force thread termination. It is ancient and deprecated Thread.stop() only (AFAIK). And no option for safe thread termination (what is why .stop() was deprecated, and allowed to be even not implemented by JVM implementors).

The reason is what all threads inside app shares memory and resources -- so, if you force termination of thread in some arbitrary point, you can't prove for sure what terminated thread does not left some shared memory/resources in inconsistent state. And you even can't (in general) suppose which resources are (possibly) dirty ('cos you dont know exactly at which point thread was stopped).

So, if you want some threads of your app to be able to interrupt, the only solution is to provide -- at design phase -- some notation of "savepoints" -- locations in target thread's code, which are guaranteed to not mutate shared state, so it is safe for thread to exit here. And it is exactly what Thread.stop() javadocs are telling you: the only way to interrupt thread safely is to design thread's code so it can by itself response to some kind of interrupt request. Some kind of flag, which is checked by thread from time to time.

I've trying to tell you: you can't do the thing you're asked about using java threading/concurrency. The way I may suggest you (it was given early here) is to do your job in separate process. Forcibly kill process is much more safe then thread since 1) processes are much more separated from each other and 2) OS takes care about many cleanups after process termination. Killing process is not completely safe, since there exists some kind of resources (files, for example) which is not cleared by OS by default, but in your case it seems to be safe.

So you design small separate application (may be even in java -- if your third-party lib does not provide other bindings, or even in shell-script) which only job is to make you computation. You start such process from main app, give it the job, and start watchdog. It watchdog detects timeout -- it kills process forcibly.

This is the only draft of solution. You can implement some kind of processes pool, if you want to improve performance (starting process may takes time), and so on...

Upvotes: 13

Vladimir Šor
Vladimir Šor

Reputation: 119

You could wrap this single call to JNI method into a separate Java application and then fork another java process with java.lang.Process. Then you can call Process.destroy() to destroy that process on the OS level.

Depending on what your environment is and other considerations you might have to do some tricks to find out how to find java executable, especially if you are building some redistributable software which could be run on different platforms. Another issue would be for you the IPC, but that could be done using Process's input/output streams.

Upvotes: 2

romje
romje

Reputation: 660

I won't repeat all precious advices given by Tudor.... I 'll just add an alternative architectural point of you while using any queing like mechanism to handle the communication between your main Java application and the native thread launched .... This thread may be client of a broker and being notified if some special events occur (termination) and acts in consequence (stopping long running job) Of course this adds some complexity but is a quite elegant solution .. Of course if the native thread is not robust it won't change anything to the whole robustness.. One way to handle communication between native thread and a broker would be to use a STOMP like interface (many brokers Apache activemq, MQ from Oracle expose such interface) ...

HTH Jerome

Upvotes: 0

Jay Tomten
Jay Tomten

Reputation: 1717

Since you are dealing with 3rd party code I would suggest creating a native shell application that handles calling, tracking and terminating these threads. Better yet get this 3rd party to do it for you if your licence agreement offers any kind of support.

http://java.sun.com/docs/books/jni/html/other.html

Upvotes: 1

Related Questions