4:42 a.m.
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 ?
Thanks.
Mohammed.
2:50 p.m.
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
3:19 a.m.
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:
3:55 a.m.
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 -----
5:22 a.m.
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:
8:01 a.m.
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 -----
10:22 a.m.
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(a)redhat.com> wrote:
12:06 p.m.
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:
7:33 p.m.
Fixed: https://issues.jboss.org/browse/UNDERTOW-593
Stuart
----- Original Message -----
3373
days inactive
3493
days old
10 comments
3 participants
participants (3)
-
Jason Greene -
Mohammed ElGhaouat -
Stuart Douglas