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(a)redhat.com>
> *To: *jboss-as7-dev(a)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/...
>
> 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(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
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)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