[concurrency-interest] Making ExecutorService return on first failure?

Joe Bowbeer joe.bowbeer at gmail.com
Fri Mar 13 17:49:59 EDT 2009


shutdownNow will interrupt actively executing tasks, and return a list of
pending (queued) tasks.

If I follow you scenario, the caller of shutdownNow should also cancel()
each of the returned tasks.

Your tasks should also be responsive to interrupt, but they will be canceled
nonetheless, which should satisfy invokeAll.  invokeAll will not wait on
canceled tasks.

Joe

On Fri, Mar 13, 2009 at 2:06 PM, jason marshall wrote:

> I tried this out.  Catch block in the Callable, pass the Executor in as an
> argument, call shutdownNow() in the catch block. Catch block fires, this
> much I can see in the logs.  What I can also see in the thread dump is that
> invokeAll() is still waiting for a ship that will never come.
>
> Looks like I'll have to be looking at CompletionService, although it looks
> a bit messier.  I'll have to manage the timeout values myself, for one.
>
>
>
>
> On Thu, Mar 12, 2009 at 1:02 PM, Outside - Karl's ACM wrote:
>
>> ExecutorService can be scheduled or canceled from any thread, but that
>> means wrapping all of your callables in wrappers tooled with the abort code.
>>
>> Is CompletionService suitable for your needs? It too wraps all callables
>> you submit to it inside some task management code so you won't have to.
>>
>> // -- begin
>> ExecutorService exec = Executors.newFixedThreadPool(3);
>> ExecutorCompletionService<?> completion = new
>> ExecutorCompletionService<?>(exec);
>> // submit 2 ok quick running tasks, 1 quick excepting task
>> // submit 1 LONG running task
>>
>> while(false == exec.isShutdown()) {
>>    try {
>>        Future<?> f = completion.take();
>>    } catch (Exception e) {
>>        exec.shutdownNow();
>>    }
>> }
>> // -- end
>>
>> That will do what you want in a procedural manner... except that it shuts
>> down all tasks as soon as you hit an exception. So you will need to define a
>> new executor for each batch of dependent tasks. It looks like that is
>> acceptible.
>>
>> I've started to have some doubt of the universal utility of
>> CompletionService - feeling that it may be better in most cases to go down
>> to implementing with blocking queues themselves instead of composing nested
>> or inter-dependent tasks inside of the CompletionService (there's a blog
>> post brewing in this after I explore the topic).
>>
>> -karl
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090313/d8b87b8c/attachment.html>


More information about the Concurrency-interest mailing list