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

jason marshall jdmarshall at gmail.com
Sat Mar 14 17:42:49 EDT 2009

Okay.  That means I'm doing what shutdownNow would normally do, in order to
keep from getting deadlock.

I ended up going with Karl's suggestion.  It's not as unreadable as I
feared.  In fact it reads better than the other two solutions (all of the
executor lifecycle management is in the same method).


On Fri, Mar 13, 2009 at 2:49 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:

> 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
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

- Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090314/b32e990b/attachment.html>

More information about the Concurrency-interest mailing list