Just adding this comment which is a summary of a short discussion I had with Brian on this topic.

A couple things come into play here:

* Executors we use for running async service tasks should always be configured to never reject tasks while they are up and running.  Limiting server load is always best done at the "front end" where requests are originally generated, not at the thread pool.
* Any executor which was brought in as a (possibly even transitive) dependency to a service can safely be assumed to be up and running at the time start or stop is called, until the time that stop is complete (whether that happens synchronously or asynchronously does not matter).

So in any case where both of these points are true (and it should always be the case, else it's a bug) we do not have to handle RejectedExecutionException, though of course it does little harm to do so other than just having code that isn't used.