If the web subsystem config is going to change, I'd like to see if it
can be made to work the way JCA does[1] -- a config element aligned with
the appropriate pool type in the jboss-as-threads.xsd.
[1]
Good thing you looked at the code. I assumed that it impacted the
threads. I guess the defaults have always been big enough for all the
tests I have done then. We should open a JIRA on JBoss Web to add the
maxThreads attribute to the XML schema that goes into domain.xml and
standalone.xml, and have it defined as read-write, so this can be changed.
Andy
------------------------------------------------------------------------
*From: *"Benjamin Browning" <bbrowning(a)redhat.com>
*To: *"Andrig Miller" <anmiller(a)redhat.com>
*Cc: *"jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
*Sent: *Thursday, October 20, 2011 12:02:56 PM
*Subject: *Re: Controlling Maximum Number of JBoss Web HTTP Threads
The max-connections attribute has no impact on the maximum http
threads. If you look at the code, all it does is set the maximum
poller size and sendfile size for the underlying JIoEndpoint.
To control the threads you either have to use an external executor
or set the maxThreads attribute on the protocol handler (which in
turn sets it on the underlying JIoEndpoint).
Ben
On Oct 20, 2011, at 1:47 PM, Andrig Miller wrote:
Ben,
I think all you have to do is set max-connections="n" to the
number of threads you want. That's what I have been doing, and
based on looking at the running threads through JConsole, it
seems to work just fine. In terms of the executor attribute, and
setting up a pool using JBoss Threads, I have done extensive
testing. I usually see only a small degradation between the two,
like around 1% or so.
Of course, that may vary based on what executor you choose to
use, but I was using the unbounded queue thread thread pool with
good success. I also changed the keepalive time, to keep the
threads around for at least an hour, so to avoid churn in my
testing between executions.
Andy
------------------------------------------------------------------------
*From:*"Benjamin Browning" <bbrowning(a)redhat.com
<mailto:bbrowning@redhat.com>>
*To:*"Andrig Miller" <anmiller(a)redhat.com
<mailto:anmiller@redhat.com>>
*Cc:*"jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>Development"
<jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
*Sent:*Thursday, October 20, 2011 10:32:01 AM
*Subject:*Controlling Maximum Number of JBoss Web HTTP Threads
I split this thread off from "Two thread pools section in
management API" since it's not directly related.
In my testing I was never able to create an executor for
JBoss Web that didn't have dismal performance. Since
TorqueBox needs to be able to easily control the maximum
number of http threads we've written a simple service that
reads a system property and sets the http connector's
protocol handler's maxThreads. This works great and doesn't
incur the performance hit of using a separate executor. If
there's interest, we could submit a patch upstream to accept
a max-threads attribute on the connector definitions.
Ben
On Oct 20, 2011, at 12:15 PM, Andrig Miller wrote:
One thing that I have found with playing around with the
various subsystems, is JBoss Web. JBoss Web doesn't
expose a thread pool configuration, just a single
attribute called max-connections. It also then has an
"executor" attribute, which just takes a thread pool
name from the JBoss Threads configuration.
So, this one is inconsistent with the other subsystems,
and I'm not sure if it should be changed to be
consistent or not, since the default doesn't use JBoss
Threads. This would also complicate any "global" view in
the console.
Andy
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev