[undertow-dev] Resizing undertow thread pool size dynamically

Mohammed ElGhaouat melghaouat at gmail.com
Mon Oct 19 11:22:58 EDT 2015


Is this valid for Wildfly? (I am using 8.2.1)

>From the previous replies, I understood that the ServletExtension could be
used for embedded Undertow not for Wildfly. Anyway, I gave it a try, but
still having Wildfly using task-max-threads and io-threads parameters from
(subsystem=io/worker=default/).

To test this solution, I created a simple wepapp with one simple Servlet
and my ServletExtension.handleDeployment is executed by the Wildfly.


Thanks

On Sat, Oct 17, 2015 at 3:01 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Like I said, you can use any thread pool you want if you modify it using a
> ServletExtension.
>
> Code looks like:
>
>
> public class MyExtension implements ServletExtension {
>
>     @Override
>     public void handleDeployment(DeploymentInfo deploymentInfo,
> ServletContext servletContext) {
>        Executor myThreadPool = {my thread pool};
>        deploymentInfo.setExecutor(myThreadPool);
>     }
> }
>
> Then add a META-INF/services entry for the extension.
>
> Stuart
>
> ----- Original Message -----
> > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>
> > Cc: "Jason Greene" <jason.greene at redhat.com>,
> undertow-dev at lists.jboss.org
> > Sent: Wednesday, 14 October, 2015 12:22:20 PM
> > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> dynamically
> >
> > Hello,
> >
> > I would like to share with you some more details about our situation. We
> > are using some big machines that are shared by many software(many Wildfly
> > instances, Databases, ERPs ..) If i don't set pools sizes i end up with
> big
> > pools as the default size is dependent on the number of CPU cores and out
> >  system administrator is complaining about the OS spending time checking
> if
> > the threads have something to do and this impact the other softwares
> > installed on the same machine. If I set a small pool size which could
> > sufficient in the 90% of time, i am afraid that  Wildfly couldn't handle
> > the 10% of time when the applications are used by a large number of user.
> >
> > Is there any workaround or are you planning to let the user to set a
> > specific ThreadPoolExecutor ? so we can evict idle threads
> >
> >
> > Thanks,
> >
> > Mohammed.
> >
> >
> > On Wed, Aug 12, 2015 at 11:03 AM, Mohammed ElGhaouat <
> melghaouat at gmail.com>
> > wrote:
> >
> > > I am using Wildfly.
> > >
> > > Thanks,
> > >
> > > Mohammed.
> > >
> > > On Wed, Aug 12, 2015 at 10:55 AM, Stuart Douglas <sdouglas at redhat.com>
> > > wrote:
> > >
> > >> 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.
> > >>
> > >> Stuart
> > >>
> > >> ----- Original Message -----
> > >> > From: "Mohammed ElGhaouat" <melghaouat at gmail.com>
> > >> > To: "Jason Greene" <jason.greene at redhat.com>
> > >> > Cc: undertow-dev at lists.jboss.org
> > >> > 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.
> > >> >
> > >> >
> > >> > Mohammed.
> > >> >
> > >> > On Tue, Aug 11, 2015 at 9:50 PM, Jason Greene <
> jason.greene at redhat.com
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> >
> > >> > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat <
> > >> melghaouat at gmail.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
> > >> > undertow-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > >>
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20151019/9b43b5d1/attachment.html 


More information about the undertow-dev mailing list