We Keep Coding

How to reset interrupted flag in executorservice.invokeAll()

I've learnt that it is the good practice to set Thread.interrupter() flag back to true after catching a InterruptedException.
However when I call executorService.invokeAll() and put a try clause around it, by catching the InterruptedException, will Thread.currentThread().interrupt() correctly flag the interrupted thread, or the main thread of my controller/runner?
public class Controller {
public void run() {
final List<Task> tasks = request.collectTasks()
try {
executorService.invokeAll(tasks);
} catch (InterruptedException e) {
message = "interrupted";
Thread.currentThread().interrupt();
throw new InternalFailureException(message);
}
}
}
class Task implements Callable<String> {
#Override
public String call() {
return taskId;
}
}
Overall is this the correct way to reset the interrupted flag?

In this code example you have given
try {
executorService.invokeAll(tasks);
} catch (InterruptedException e) {
message = "interrupted";
Thread.currentThread().interrupt();
throw new InternalFailureException(message);
}
whoever invokes Thread.currentThread().interrupt(); will set the flag of that thread in this example it will be the thread executing your Controller#run() method.
Ideally with executors it is the responsibility of Task or Runnable which gets scheduled over the executor to handle this flag properly.
Since it is a checked exception already - it will not give you an opportunity to decorate the task that you are about to submit inside executor so you have no easy control over it.

Why does BoundedExecutor have to catch RejectedExecutionException?

As to BoundedExecutor in the book Java Concurrency in Practice, task submission has been throttled by semaphore. When would the underlying executor throw a RejectedExecutionException? Maybe when operating system runs out of threads?
public class BoundedExecutor {
private final Executor exec;
private final Semaphore semaphore;
public BoundedExecutor(Executor exec, int bound) {
this.exec = exec;
this.semaphore = new Semaphore(bound);
}
public void submitTask(final Runnable command) throws InterruptedException, RejectedExecutionException
{
semaphore.acquire();
try {
exec.execute(new Runnable() {
#Override public void run() {
try {
command.run();
} finally {
semaphore.release();
}
}
});
} catch (RejectedExecutionException e) {
semaphore.release();
throw e;
}
}
}

Part of the contract of Executor.execute() is that it can throw a RejectedExecutionException:
if this task cannot be accepted for execution
What that means for any given Executor implementation is up to the discretion of that implementation. I could create an OnlyOnSundaysExecutor that rejects tasks unless the current day of the week is Sunday. You would have to check the documentation for the various Executor implementations to see under what circumstances they would throw a RejectedExecutionException exception.

Regardless of the circumstances under which an exception might be thrown, it is important to keep your application in a consistent state, even when exceptions occur.
Here, the semaphore that has been acquired should always get released. For most resources that should get released under all circumstances, you would use a try {} finally { /* release action */ } construct to ensure the release even in the exceptional case, but here, we have the special situation that the release action should be performed only in the exceptional case, as in the successful case, the submitted Runnable will perform the release action (note that within the Runnable, finally is indeed being used).
So the code is supposed to handle the case when a RejectedExecutionException is thrown. We might want to do that for every RuntimeException or Error, but the problem is, RejectedExecutionException is the only exception type where we know for sure that the runnable will never get executed. For all other kinds of exceptions, it is possible that it will still run.
To make the cleanup safe, you would need another atomic toggle:
public void submitTask(final Runnable command) throws InterruptedException {
AtomicBoolean proceed = new AtomicBoolean(true);
semaphore.acquire();
try {
exec.execute(new Runnable() {
#Override public void run() {
if(proceed.compareAndSet(true, false)) try {
command.run();
} finally {
semaphore.release();
}
}
});
} catch(Throwable e) {
if(proceed.compareAndSet(true, false)) semaphore.release();
throw e;
}
}
Now, in every exceptional case, an attempt to release the semaphore will be made, unless the Runnable flagged that it is already running. Or the Runnable will not proceed if it detects that the semaphore has been released due to an exception in the submitting code.
This is, of course, more complicated than the book example and possibly distracting from the original intent of the example. Also, it uses the Java 7 feature of being able to easily catch and re-throw all possible exceptions of the try block. This wasn’t available when the book was written.

Stopping a Thread / Threads calls interrupt on itself after crash?

I am currently running a Thread from a Service to do some background work.
Now there is the possibility that the Thread crashes or I want to
interrupt the thread from the Service. So how am I supposed to:
stop the Thread realiable, (hard)
catch exceptions and call the Service about the crash
handle InterruptedException if interrupted while sleep()
is Thread.isInterrupted a good way to detect if the Thread stopped?
What I have done so far is the following:
#Override
public void run() {
try {
while (!Thread.currentThread().isInterrupted()) {
doMyBackgroundWork();
sleep();
}
}catch(Exception e){
ExceptionHandler.logAndSendException(e);
Thread.currentThread().interrupt();
if(crashedListener != null){
crashedListener.onThreadCrashed();
}
}
LOG.i("Thread stops now.");
}
private void sleep() {
try {
sleep(frequency);
} catch (InterruptedException e) {
//what to do here? it can happen because I stopped it myself
}
}
So at first I am running my Thread until it gets interrupted.
If any exception occurs, I want to start a new Thread, therefore
my Service implements a listener interface and I call it, once an
Exception is thrown. I know that catching everything is discouraged,
but I need to know if the Thread stops, without polling Thread.isAlive()
all the time.
Additionally to my four questions above:
is my code reliable and does what I need?
is it ok to call interrupt on the Thread itself?
Thanks!

You are not actually interrupting your own thread because the catch block is outside of the while loop. Therefore, any exception would stop execution immediately.
Interruption is essentially just a request (usually from another thread) to stop doing what you are doing. The thread is free to ignore it and keep doing what it is doing. Normally you have to throw an exception in response to an interrupt, or stop execution some other way such as just breaking from the loop (you need this around the //what to do here? comment). It so happens that some library methods are "responsive to interruption" meaning they will throw an exception if the thread is ever interrupted, such as Thread.sleep(), which you will most likely have in your sleep call.
I recommend picking Java Concurrency In Practice. Among the excellent concurrency material, there is a chapter on interrupts which is very helpful.
EDIT:
I would remove the code where you interrupt your own thread. You will also need to rethrow the InterruptedException as a runtime exception to get out of the execution loop. Usually people will create a new Exception that extends RuntimeException that is something like MyInterruptedException. You can then add it to the catch block around your loop so that you know when the thread was interrupted vs execution failed.
As a general example you can do something like this:
public void run() {
try {
while (true) {
// check for interrupts in the loop, or somewhere in the work method
if (Thread.interrupted()) {
throw new MyInterruptedException("Important thread interrupted.");
}
doMyBackgroundWork();
sleep();
}
}
catch(Exception e){
ExceptionHandler.logAndSendException(e);
if(crashedListener != null){
crashedListener.onThreadCrashed();
}
}
catch(MyInterruptedException i) {
LOG.i("Execution stopping because of interrupt.");
}
}
private void sleep() {
try {
sleep(frequency);
} catch (InterruptedException e) {
throw new MyInterrptedException(e);
}
}

we have a nice and effective method called stop()(Thread.stop(void):void) which is deprecated, but it works and it's lovely.
Note that stop() throws ThreadDeath at the target thread which is not an exception(and it could any other throwable too), but an Error, so your code will not catch any signal about this.
public void run() {
try {
while (<<using_a_volatile_bool_type_is_better>>) {
...
}
}catch(Throwable t){/**/}/*use throwable instead of exception.*/}
}
Beside dear friend stop() we also have pause() method too, and it really pauses the target thread.
Not just one solution out there, but if it's really critical to keep thread run and run the emergency(or itself) just after any crash, you may run it as a separately app/process, plus get progress status(if any) that ensures you the target thread/app is not freezed(blocked,...)

The Cause of InterruptedException

From J2me doc we know that:
java.lang.InterruptedException Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it.
The question is if it's posible to get such exception if from one thread i call Thread.Interupt() for other thread where Run() method of other thread waiting on InputStream.Read(char[]buf) ?

The behavior of blocking read in response to thread interrupt is, in fact, undefined. See this long-standing bug for details. The short of it is that sometimes you get EOF, sometimes you get IOException.

Unfortunately, no, the java.io.* classes do not respond to interruptions when they are blocked in read or write methods. Typically what you have to do is close the stream and then handle the IOException that gets thrown. I have this pattern repeated throughout my code:
try {
for (;;) {
try {
inputStream.read(data);
thread.join();
}
catch (IOException exception) {
// If interrupted this isn't a real I/O error.
if (Thread.interrupted()) {
throw new InterruptedException();
}
else {
throw exception;
}
}
}
}
catch (InterruptedException exception) {
}
Alternatively the newer java.nio.* classes do handle interruptions better and generate InterruptedIOExceptions when they are interrupted. Note that this exception is derived from IOException and not from InterruptedException so you will probably need two catch clauses to handle either type of exception, one for InterruptedException and one for InterruptedIOException. And you'll want any inner IOException catch clause to ignore InterruptedIOExceptions.

How to throw a checked exception from a java thread?

Hey, I'm writing a network application, in which I read packets of some custom binary format. And I'm starting a background thread to wait for incoming data. The problem is, that the compiler doesn't let me to put any code throwing (checked) exceptions into run(). It says:
run() in (...).Listener cannot implement run() in java.lang.Runnable; overridden method does not throw java.io.IOException
I want the exception to kill the thread, and let it be caught somewhere in the parent thread. Is this possible to achieve or do I have to handle every exception inside the thread?

To be able to send the exception to the parent thread, you can put your background thread in a Callable (it allows throwing also checked exceptions) which you then pass to the submit method of some Executor. The submit method will return a Future which you can then use to get the exception (its get method will throw an ExecutionException which contains the original exception).

Caveat: this may not meet your needs if you have to use the exception mechanism.
If I understand you correctly, you don't actually need the exception to be checked (you've accepted the answer suggesting an unchecked exception) so would a simple listener pattern be more appropriate?
The listener could live in the parent thread, and when you've caught the checked exception in the child thread, you could simply notify the listener.
This means that you have a way of exposing that this will happen (through public methods), and will be able to pass more information than an exception will allow. But it does mean there will be a coupling (albeit a loose one) between the parent and the child thread. It would depend in your specific situation whether this would have a benefit over wrapping the checked exception with an unchecked one.
Here's a simple example (some code borrowed from another answer):
public class ThingRunnable implements Runnable {
private SomeListenerType listener;
// assign listener somewhere
public void run() {
try {
while(iHaveMorePackets()) {
doStuffWithPacket();
}
} catch(Exception e) {
listener.notifyThatDarnedExceptionHappened(...);
}
}
}
The coupling comes from an object in the parent thread having to be of type SomeListenerType.

This answer is based on Esko Luontola one but it provides a working example.
Unlike the run() method of the Runnable interface the call() method of Callable allows to throw some exceptions. Here is an implementation example :
public class MyTask implements Callable<Integer> {
private int numerator;
private int denominator;
public MyTask(int n, int d) {
this.numerator = n;
this.denominator = d;
}
#Override
// The call method may throw an exception
public Integer call() throws Exception {
Thread.sleep(1000);
if (denominator == 0) {
throw new Exception("cannot devide by zero");
} else {
return numerator / denominator;
}
}
}
Executor provides a mechanism to run a Callable inside a thread and to handle any kind of exceptions :
public class Main {
public static void main(String[] args) {
// Build a task and an executor
MyTask task = new MyTask(2, 0);
ExecutorService threadExecutor = Executors.newSingleThreadExecutor();
try {
// Start task on another thread
Future<Integer> futureResult = threadExecutor.submit(task);
// While task is running you can do asynchronous operations
System.out.println("Something that doesn't need the tasks result");
// Now wait until the result is available
int result = futureResult.get();
System.out.println("The result is " + result);
} catch (ExecutionException e) {
// Handle the exception thrown by the child thread
if (e.getMessage().contains("cannot devide by zero"))
System.out.println("error in child thread caused by zero division");
} catch (InterruptedException e) {
// This exception is thrown if the child thread is interrupted.
e.printStackTrace();
}
}
}

What I do is to catch the exception in the thread and store it as a member variable of the Runnable. This exception is then exposed via a getter on the Runnable. I then scan all the threads from the parent to see if any had exceptions, and take the appropriate action.

If you really cannot do anything useful when the exception is raised you can wrap the checked exception in a RuntimeException.
try {
// stuff
} catch (CheckedException yourCheckedException) {
throw new RuntimeException("Something to explain what is happening", yourCheckedException);
}

the thread can't throw the exception to any other thread (nor to the main thread). and you cannot make the inherited run() method throw any checked exceptions since you can only throw less than the inherited code, not more.

If your thread's code throw a RuntimeExpection, you doesn't need to add run() throw Exception.
But use this solution only when appropriate because this can be a bad pratice:
http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html
Any RuntimeException or unchecked Exception can help you. Maybe you'll need to create your own RuntimeException

On the assumption that your code is in some kind of loop, you'd write:
public class ThingRunnable implements Runnable {
public void run() {
try {
while(iHaveMorePackets()) {
doStuffWithPacket()
}
} catch(Exception e) {
System.out.println("Runnable terminating with exception" + e );
}
}
}
The exception will automatically break you out of your loop, and at the end of the run() method, the thread will stop.

Use this Runnable to create your Thread:
public abstract class TryRunner implements Runnable{
protected abstract void tryToRun();
protected void onException(Exception e){}
#Override
final public void run() {
try{ tryToRun(); }catch(Exception e){ e.printStackTrace(); onException(e); }
}
}

Wrapping your exception inside a RuntimeException seems to do the trick.
someMethod() throws IOException
{
try
{
new Thread(() ->
{
try
{
throw new IOException("a checked exception thrown from within a running thread");
}
catch(IOException ex)
{
throw new RuntimeException("a wrapper exception", ex); // wrap the checked exception inside an unchecked exception and throw it
}
}).start();
}
catch(RuntimeException ex) // catch the wrapped exception sent from within the thread
{
if(ex.getCause() instanceof IOException)
throw ex.getCause; // unwrap the checked exception using getCause method and use it however you need
else
throw ex;
}
}