How to catch exceptions inside a ThreadPool

[kalsan]

We are using FixedThreadPools in a large Rails application. Due to the size of the project, we have a large variety of control flows including returns and all kinds of exceptions.

In order to deal with exceptions inside a FixedThreadPool, we are forced to use a workaround with a block with_exception_catching do...end, but it's a terribly ugly hack that is becoming harder and harder to maintain as our application grows in complexity.

Despite long hours of research, we haven't found a cleaner solution in the Internet. Interestingly, not long ago someone else has come up with a similar workaround here: http://stackoverflow.com/questions/40718759/handle-exceptions-in-concurrent-ruby-thread-pool (Reply by grossadamm).

Not being able to deal with exceptions inside threads is a problem that affects so many people. I can't believe there isn't already a solution implemented in FixedThreadPool. So I've got to come up with this question: Isn't there a cleaner way to do this?

[jdantonio]

Most applications should not use thread pools directly. Thread pools are a low-level abstraction meant for internal use. All of the high-level abstractions in this library (Promise, Actor, etc.) all post jobs to the global thread pool and all provide exception handling. Simply pick the abstraction that best fits your use case and use it.

If you feel the need to configure your own thread pool rather than use the global thread pool, you can still use the high-level abstractions. They all support an :executor option which allows you to inject your custom thread pool. You can then use the exception handling provided by the high-level abstraction.

If you absolutely insist on posting jobs directly to a thread pool rather than using our high-level abstractions (which I strongly discourage) then just create a job wrapper. You can find examples of job wrappers in all our high-level abstractions, Rails ActiveJob, Sucker Punch, and other libraries which use our thread pools.

PS: WRT "I can't believe there isn't already a solution implemented in FixedThreadPool." Please take a look at Java's ThreadPoolExecutor. You'll notice that our API is exactly the same (in fact, on JRuby) our TPE is just a thin wrapper around Java's). The reason that neither Java's thread pools nor ours have exception handling within the thread pool is because that's not the appropriate place to put it. Exception handling is an application-level concern that is unique to each application. Therefore it is best handled by the application programmer, not the low-level abstraction.

[kalsan]

Thanks a lot for your answer! This makes things a lot clearer. I think we will give Promise a go, it's looking good so far.

Concerning "I can't believe there isn't already a solution implemented in FixedThreadPool" : It now turns out the sentence was ill-formulated; I should have said: "I can't believe there isn't already a solution in a ThreadPool-like structure in RubyConcurrent." I'm happy that this is yet another case where the gem is thought through all the way. We're impressed by the high quality of the library.

[jdantonio]

:-)

[pitr-ch]

@kalsan you could also have a look at edge Promises. They will go to 1.1 and old Promise, Future will be deprecated. You might safe a migration, and we appreciate feedback before 1.1. is released.

[beatgutzwiller]

@pitr-ch I take the freedom to answer for my colleague kalsan. We have implemented a very simple multithreading with promises. Now i've tried the same with the edge Promises. In our case it makes no difference and works perfectly.

But i have still one big question. Since we also use Multithreading in Unit tests, we have to propagate all errors back to the main thread. Currently we collect the erros like that (Note there are also some puts for debugging):

promises.each do |p|
   # p.value will block until the thread is finished
   next unless p.value.nil? && p.rejected?
   puts "From Promise with number: #{number}".magenta
   puts p.reason.inspect.red
   collected_exceptions << p.reason
   number += 1
 end
 unless collected_exceptions.empty?
   puts
   puts "Done with #{collected_exceptions.count} exceptions.".magenta
   fail collected_exceptions.first
 end

This works actually quite good. But it isn't the neatest approach,
So my question is, how would you do that, how do you wait for all Promises and propagate erros.
I can't really find an answer in the documentation.
Forgive me my silly question if it is obvious and I just don't get it.

[pitr-ch]

@beatgutzwiller That's a good question. May following examples be helpful:

# make sure that the future fulfilled, we do not care about the value here, 
# raises if rejected failing the test
promise.wait!

# test a result, value! will raise reason if rejected
assert promise.value! == an_expected_value

# testing many promises
promises.each { |p| assert promise.value! == an_expected_value }
# the above approach avoids the reason collection
# if only first failure is not enough though I would do
assert Promises.zip(*promises).value! == [an_expected_value,an_expected_value, ...]

# testing rejections
assert promise.wait.rejected?
assert AnErrorClass === promise.reason

[beatgutzwiller]

@pitr-ch Thank you very much. Exactly what i searched. Thank you all for the good work, this library is quite awesome once you get the hang of it.

[kalsan]

Thanks everybody!

[beatgutzwiller]

Just a note if somebody will have the same problem as I have.
Concurrent::Promise.zip(*promises).value only collects values until an Error happens.
So Concurrent::Promise.zip(*promises).value! will only propagate 1 Error, and
Concurrent::Promise.zip(*promises).reason will only contain 1 error, and only the values until the Error happened
But with the Edge gem it works as i want
Concurrent::Promises.zip(*promises).value! Throws all exceptions caught, with an Counter.