[undertow-dev] Resizing undertow thread pool size dynamically

Mohammed ElGhaouat melghaouat at gmail.com
Wed Oct 14 06:22:20 EDT 2015


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/20151014/89d14ac0/attachment-0001.html 


More information about the undertow-dev mailing list