Are you using Wildfly or embedded Undertow?
If it is the later you can just use io.undertow.servlet.api.DeploymentInfo#setExecutor to use whatever executor implementation you want.
The reason why most executors don't reduce the number is because there is generally very little point, a parked thread is generally very cheap, while creating new threads is relatively expensive.
----- Original Message -----
> From: "Mohammed ElGhaouat" <email@example.com>
> To: "Jason Greene" <firstname.lastname@example.org>
> Cc: email@example.com
> Sent: Wednesday, 12 August, 2015 6:19:11 PM
> Subject: Re: [undertow-dev] Resizing undertow thread pool size dynamically
> We are using the servlet API and I am referring to worker pool. Simply we
> don't want keeping bunch of idle threads in the JVM consuming some resources
> without doing any thing useful.
> So with the bounded queue executor, when the value of the task-max-threads
> parameter is reached, the number of threads in the worker pool couldn't be
> decreased ?
> Thank you.
> On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene < firstname.lastname@example.org >
> > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat < email@example.com >
> > wrote:
> > Hi,
> > I would like to know if there is a way to make undertow reducing the size
> > of the thread pool when the server is less loaded. Is there any
> > parameter(or other way) that make an idle thread die after some inactivity
> > time ?
> Are you referring to the worker pool or the I/O pool? The I/O pool is special
> and is fixed. The worker pool currently uses a JDK ThreadPoolExecutor with
> an unbounded queue which is a behavior pattern typically desired for web
> servers. That’s not pluggable at the moment, but it could be possible.
> If you are using the HttpHandler APIs, there is a method on
> HttpServerDispatch that allows you to use your own custom executor for
> blocking tasks (which would allow you to tune the default worker task pool
> very small). If you are using servlet APIs though that uses the standard
> pools we provide.
> Is there a particular reason you want to kill idle threads? Threads are cheap
> unless you are storing massive amounts of thread local data.
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> undertow-dev mailing list