[undertow-dev] Resizing undertow thread pool size dynamically
Mohammed ElGhaouat
melghaouat at gmail.com
Tue Dec 8 13:06:57 EST 2015
Hello,
this doesn't work for me. I dug a little bit in undertow code and it seems
to me that the *deploymentInfo.executor *we set in the ServletExtension is
not used by *DeploymentImpl *class, the *DeploymentImpl.getExecutor* returns
the field *executor*
@Override
public Executor getExecutor() {
return executor;
}
while in the constructor we have
public DeploymentImpl(DeploymentManager deploymentManager, final
DeploymentInfo deploymentInfo, ServletContainer servletContainer) {
............
* this.executor = deploymentInfo.getExecutor();*
............
}
when i changed the getExecutor method to
@Override
public Executor getExecutor() {
return deploymentInfo.getExecutor();
}
I got my executor that I set in the ServletExtension used by Wildfly.
Is this explanation seems right to you ?
Thanks
Mohammed.
On Mon, Oct 19, 2015 at 10:19 PM, Stuart Douglas <sdouglas at redhat.com>
wrote:
>
>
> ----- 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: Tuesday, 20 October, 2015 2:22:58 AM
> > Subject: Re: [undertow-dev] Resizing undertow thread pool size
> dynamically
> >
> > Is this valid for Wildfly? (I am using 8.2.1)
>
> Yes, this is valid for all Servlet deployments, in both Wildfly and
> embedded Undertow.
>
> Wildfly will still create its worker thread pool, but it should not get
> used for this deployment.
>
> Stuart
>
> >
> > 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/20151208/f031f49a/attachment-0001.html
More information about the undertow-dev
mailing list