Iter/feedback

Author: DaveCTurner

server/src/main/java/org/elasticsearch/threadpool/ThreadPool.java

@@ -25,6 +25,7 @@
 import org.elasticsearch.common.util.concurrent.EsRejectedExecutionHandler;
 import org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor;
 import org.elasticsearch.common.util.concurrent.ThreadContext;
+import org.elasticsearch.common.util.concurrent.ThrottledTaskRunner;
 import org.elasticsearch.core.Nullable;
 import org.elasticsearch.core.TimeValue;
 import org.elasticsearch.node.Node;
@@ -74,20 +75,28 @@ public class ThreadPool implements ReportingService<ThreadPoolInfo>, Scheduler,
      */
     public static class Names {
         /**
-         * A thread pool with a very high (but finite) maximum size for when there really is no other choice.
+         * A thread pool with a very high (but finite) maximum size for use when there really is no other choice.
          * <p>
          * This pool may be used for one-off CPU-bound activities, but the maximum size is so high that it doesn't really work well to do a
-         * lot of CPU-bound work in parallel here. Likewise you can do IO on this pool, but using it for lots of concurrent IO is likely
-         * harmful in clusters with poor concurrent IO performance (especially if using spinning disks). Blocking on a future on this pool
+         * lot of CPU-bound work in parallel here: submitting more CPU-bound tasks than we have CPUs to run them will burn a lot of CPU just
+         * context-switching in order to try and make fair progress on all the tasks at once. Better to submit fewer tasks and wait for them
+         * to complete before submitting more. See {@link ThrottledTaskRunner} and friends for utilities to help with this.
+         * <p>
+         * Likewise you can do IO on this pool, but using it for lots of concurrent IO is likely
+         * harmful in clusters with poor concurrent IO performance (especially if using spinning disks).
+         * <p>
+         * Blocking on a future on this pool
          * risks deadlock if there's a chance that the completion of the future depends on work being done on this pool. Unfortunately
          * that's pretty likely in most cases because of how often this pool is used; it's really rare because of the high limit on the pool
-         * size, but when it happens  it is extremely harmful to the node.
+         * size, but when it happens it is extremely harmful to the node.
          * <p>
          * This pool is also used for recovery-related work. The recovery subsystem bounds its own concurrency, and therefore the amount of
          * recovery work done on the {@code #GENERIC} pool, via {@code cluster.routing.allocation.node_concurrent_recoveries} and related
          * settings.
          * <p>
-         * This pool does not reject any task. If you submit a task after the pool starts to shut down, it may simply never run.
+         * Other subsystems
+         * <p>
+         * This pool does not reject any task. Tasks you submit to this executor after the pool starts to shut down may simply never run.
          */
         public static final String GENERIC = "generic";