When every thread in an Elasticsearch pool is busy and the queue behind it is full, the next request gets rejected with a 429 TOO_MANY_REQUESTS and an EsRejectedExecutionException. This is backpressure - the node cannot accept more work of that type. The practical question is whether to tune the pool, add capacity, or fix the workload that's overwhelming it.
Thread Pool Types and Their Defaults
Each pool has a type (fixed or scaling), a thread count, and a queue size. Fixed pools have a hard ceiling on threads and a bounded queue. Scaling pools grow and shrink based on load.
write - Indexing, bulk, update, and delete operations. Fixed pool. Threads: allocated processors, capped at 1 + processors. Queue: max(10000, processors * 750).
search - _search, _count, _msearch, and suggest. Fixed pool. Threads: int(processors * 3 / 2) + 1. Queue: 1000.
get - Real-time GET by document ID. Fixed pool. Threads: allocated processors. Queue: 1000.
analyze - _analyze API calls. Fixed pool. 1 thread, queue 16. Text analysis is a diagnostic tool, not a production path.
snapshot - Handles snapshot and restore operations. Scaling pool. Max threads: min(5, processors / 2) on nodes with less than 750MB heap, otherwise 10.
force_merge - Fixed pool. Thread count: max(1, processors / 8). Unbounded queue since force merges are serialized per shard.
management - Cluster state updates and administrative operations. Scaling pool. Maximum 5 threads.
How Rejections Happen
A rejection occurs in a fixed pool when threads equal the pool size, every thread is executing a task, and queued tasks equal the queue size. The next submitted task gets rejected immediately. The node does not wait or retry.
For bulk indexing, the relationship between client-side batch count and server-side queue consumption is not one-to-one. A single bulk request targeting 10 shards on one node consumes 10 queue slots, not one. This is why a moderately-sized bulk request can still trigger rejections - the shard fan-out multiplies queue pressure. Reduce shard count per index or route bulk requests more evenly across nodes to mitigate this.
Search rejections follow the same mechanics. Heavy aggregation queries, especially those that fan out across many shards, consume search threads for longer durations than simple term queries. A node with 200 shards receiving a _search request against * will need a thread per shard for the query phase.
Monitoring Rejections
The two primary diagnostic APIs are _nodes/stats/thread_pool and _cat/thread_pool.
GET /_nodes/stats/thread_pool/write,search,get
This returns per-node JSON with threads, queue, active, rejected, and completed counts. The rejected counter is cumulative since node start, so track the delta over time to detect bursts.
For a quick tabular view:
GET /_cat/thread_pool/write,search?v&h=node_name,name,active,queue,rejected,completed
Sample output:
node_name name active queue rejected completed
data-01 write 4 120 83 5928471
data-01 search 7 0 12 8291034
data-02 write 8 4219 2941 4102938
Node data-02 here has a write queue near capacity and a high rejection count. That node is either receiving disproportionate write traffic (hot-spotting from shard allocation) or is under-resourced relative to its peers.
Tuning Queue Size vs. Adding Capacity
Increasing queue size is the first thing most people try. It is usually the wrong fix. A larger queue means more requests buffered in memory, increasing heap pressure and raising latency for queued requests. If your clients have a 30-second timeout and the queue holds 60 seconds of work, requests time out while sitting in the queue - same failure, worse diagnostics.
Queue size increases are justified in one scenario: bursty traffic with idle periods. If your ingest pattern is 10 seconds of heavy bulk followed by 50 seconds of quiet, a deeper queue absorbs the burst and drains during the lull. For sustained load, the queue just delays the inevitable rejection while burning heap.
The right responses to sustained rejections depend on the pool:
Write rejections - Check bulk request size and shard count. Reduce the number of shards each bulk request touches. Use the _routing parameter to concentrate writes. If the workload is legitimately beyond what the nodes can handle, add data nodes.
Search rejections - Look at slow query logs. Expensive queries that hold threads for seconds are often the cause, not raw query volume. Optimize the queries, reduce shard counts (fewer shards means fewer threads per search), or add coordinator-only nodes to offload aggregation merging.
When Rejections Signal a Deeper Problem
Persistent rejections that don't respond to capacity increases usually point to a structural issue. Common patterns:
Too many small shards. A node with 2000 shards servicing a wildcard search needs 2000 threads for a single query's scatter phase. No thread pool configuration fixes this. Consolidate indices, use data streams with appropriate rollover conditions, and target 20-40 GB per shard.
Garbage collection pressure. Long GC pauses freeze all thread pools simultaneously. Check GC logs for pauses over 500ms. If a node spends more than 5% of wall clock time in GC, the heap is under pressure from field data, aggregation buffers, or too many concurrent requests holding response data.
Disk I/O saturation. Merges, flushes, and translog fsync compete for disk bandwidth. Write threads block on I/O, holding their slot longer than expected. Monitor iowait and merge rates. Faster storage or reducing merge concurrency via index.merge.scheduler.max_thread_count can help.
A thread pool rejection is a signal, not the problem itself. Treat it as an entry point for investigation, not a configuration value to tweak away.
