----- Original Message -----
From: "Remy Maucherat" <rmaucher(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Friday, October 21, 2011 1:58:38 AM
Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web
HTTP Threads
On Thu, 2011-10-20 at 15:17 -0400, 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.
I won't add it. To configure the thread pool, use an executor
instead.
It is possible to tie maxConnections to maxThreads, but I am not
convinced it is an acceptable side effect.
What do you mean you won't add it? In all the testing I have done, configuring an
executor, just so we can configure the number of threads, is actually slower from a
throughput perspective. Your really saying that we have to use something that has
consistently been slower, just so you don't have to expose maxThreads?
Come on Remy. Where's the logic in that? So, as we gear up our benchmarking work on
SPEC, we won't be able to use the faster solution, just because we won't be able
to configure it.
I think you should rethink your position. It's not exactly helping the company out
any.
Of course, I guess I could start looking at the two implementations and see why the one is
faster than the other, and change JBoss Threads so that there is no penalty, but it sure
sounds a lot easier to expose one additional attribute for configuration.
Andy
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev