[jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads

Brian Stansberry brian.stansberry at redhat.com
Thu Oct 20 17:16:55 EDT 2011


I don't know; I'd need the JBoss Web guys to answer that.

On 10/20/11 4:00 PM, Andrig Miller wrote:
> Do the configuration elements align with the default executor in JBoss
> Web, which is not the JBoss Threads implementation?
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Brian Stansberry" <brian.stansberry at redhat.com>
>     *To: *jboss-as7-dev at lists.jboss.org
>     *Sent: *Thursday, October 20, 2011 1:24:41 PM
>     *Subject: *Re: [jboss-as7-dev] Controlling Maximum Number of JBoss
>     Web HTTP Threads
>
>     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]
>     https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/docs/schema/jboss-as-jca_1_0.xsd#L120
>
>     On 10/20/11 2:17 PM, Andrig Miller wrote:
>      > 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 at redhat.com>
>      > *To: *"Andrig Miller" <anmiller at redhat.com>
>      > *Cc: *"jboss-as7-dev at lists.jboss.org Development"
>      > <jboss-as7-dev at 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 at redhat.com
>      > <mailto:bbrowning at redhat.com>>
>      > *To:*"Andrig Miller" <anmiller at redhat.com
>      > <mailto:anmiller at redhat.com>>
>      > *Cc:*"jboss-as7-dev at lists.jboss.org
>      > <mailto:jboss-as7-dev at lists.jboss.org>Development"
>      > <jboss-as7-dev at lists.jboss.org
>      > <mailto:jboss-as7-dev at 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 at lists.jboss.org
>      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     jboss-as7-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list