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(a)redhat.com>
wrote:
----- Original Message -----
> From: "Mohammed ElGhaouat" <melghaouat(a)gmail.com>
> To: "Stuart Douglas" <sdouglas(a)redhat.com>
> Cc: "Jason Greene" <jason.greene(a)redhat.com>,
undertow-dev(a)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(a)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(a)gmail.com>
> > > To: "Stuart Douglas" <sdouglas(a)redhat.com>
> > > Cc: "Jason Greene" <jason.greene(a)redhat.com>,
> > undertow-dev(a)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(a)gmail.com>
> > > wrote:
> > >
> > > > I am using Wildfly.
> > > >
> > > > Thanks,
> > > >
> > > > Mohammed.
> > > >
> > > > On Wed, Aug 12, 2015 at 10:55 AM, Stuart Douglas <
sdouglas(a)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(a)gmail.com>
> > > >> > To: "Jason Greene"
<jason.greene(a)redhat.com>
> > > >> > Cc: undertow-dev(a)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(a)redhat.com
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> >
> > > >> > > On Aug 11, 2015, at 4:42 AM, Mohammed ElGhaouat <
> > > >> melghaouat(a)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(a)lists.jboss.org
> > > >> >
https://lists.jboss.org/mailman/listinfo/undertow-dev
> > > >>
> > > >
> > > >
> > >
> >
>