[jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads
Jason T. Greene
jason.greene at redhat.com
Thu Oct 20 17:27:58 EDT 2011
Remy has indicated in the past that he does not want to expose that
level of tuning in the default jbossweb pool because of common
misuse/misconception about the settings. (IIRC he was against maxthreads
for example)
On 10/20/11 4:16 PM, Brian Stansberry wrote:
> 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
>>
>>
>
>
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
More information about the jboss-as7-dev
mailing list