You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Whatever the policy, once the container is shutting down a rejected task degrades to an observable logged drop — `BLOCK` never hangs teardown and `THROW` never throws on the shutdown path.
136
136
137
+
#### Tuning the default executor's pool size
138
+
139
+
Size the pool for your workload — more threads for I/O-bound handlers, fewer for CPU-bound. Omitting a knob keeps its processor-derived default, so these are purely additive:
`eventExecutorMetrics()` returns `Optional<ExecutorMetrics>` — a record exposing `activeCount`, `poolSize`, `queueSize`, `queueRemainingCapacity`, `completedTaskCount`, `corePoolSize`, and `maxPoolSize`. It is **empty** when you supply your own executor (its metrics are yours to expose, not the framework's).
161
+
137
162
Workloads with extreme throughput or latency requirements can supply their own executor instead:
When you supply your own executor, **you own its lifecycle** — `Container.shutdown()` does not stop it, and `queueCapacity` / `onOverflow` have no effect (your executor brings its own queue and rejection policy). Async handler exceptions still route to the configured `ErrorHandler` regardless of which executor is in use.
172
+
When you supply your own executor, **you own its lifecycle** — `Container.shutdown()` does not stop it; `queueCapacity` / `onOverflow`and the pool-size knobs have no effect (your executor brings its own queue, rejection policy, and sizing); and `eventExecutorMetrics()` returns empty. Async handler exceptions still route to the configured `ErrorHandler` regardless of which executor is in use.
0 commit comments