6:50 a.m.
I found that in the management API there are two places where thread
pools can be created:
/subsystem=threads
and
/subsystem=ejb3/thread-pool=*
It seems that the latter defines pools that are used in
/subsystem=ejb3/service=*
Should they not be using thread pools defined in the threads subsystem
instead?
Cheers,
David
6:57 a.m.
no, but if possible they should rely on the default schema (xsd) for defining inlined
thread pool configurations.
On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
It seems that the latter defines pools that are used in
/subsystem=ejb3/service=*
Should they not be using thread pools defined in the threads subsystem
instead?
9:16 a.m.
Right. What happened is we found out that having thread pools be global promotes sharing,
which is usually an error since each subsystem needs specific configurations. We were
planning on adding a global view that would see all the subsystems' thread pools so
the administrator can easily identify which were in use however I don't think it was
completed yet. Even though we neat them in the subsystem we still want them to be
consistent.
Sent from my iPhone
On Oct 20, 2011, at 5:58 AM, Heiko Braun <hbraun(a)redhat.com> wrote:
no, but if possible they should rely on the default schema (xsd) for defining inlined
thread pool configurations.
On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
> It seems that the latter defines pools that are used in
> /subsystem=ejb3/service=*
> Should they not be using thread pools defined in the threads subsystem
> instead?
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:12 a.m.
I struggled with that global view a bit over the last week.
I was thinking about approaching it as having it be a set of resources
in the threads subsystem that are basically just views onto the real
resource, which would exist in JCA, EJB etc.
That's not very satisfying. Leads to things like having to avoid
conflicts in pool names across subsystems. Plus it would be pretty hard
to implement.
I was noodling a bit this morning about separating the UI issue from the
core model a bit. The core model (in the threads subsystem) could just
provide resources addresses (and maybe a bit more metadata) about pools
configured elsewhere. The resources for pools would be consistent
throughout the model (e.g. a bounded-queue-thread-pool that supports
blocking would have the same attributes, ops, etc everywhere). The
console could use the info from the threads subsystem to discover all
the pool configs and then build a nice UI.
I suspect that's a problem for JON though. The CLI of course wouldn't be
able to produce a nice unified view, but IMHO that's not a critical problem.
On 10/20/11 8:16 AM, Jason Greene wrote:
Right. What happened is we found out that having thread pools be
global
promotes sharing, which is usually an error since each subsystem needs
specific configurations. We were planning on adding a global view that
would see all the subsystems' thread pools so the administrator can
easily identify which were in use however I don't think it was completed
yet. Even though we neat them in the subsystem we still want them to be
consistent.
Sent from my iPhone
On Oct 20, 2011, at 5:58 AM, Heiko Braun <hbraun(a)redhat.com
<mailto:hbraun@redhat.com>> wrote:
>
>
> no, but if possible they should rely on the default schema (xsd) for
> defining inlined thread pool configurations.
>
> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
>
>> It seems that the latter defines pools that are used in
>> /subsystem=ejb3/service=*
>> Should they not be using thread pools defined in the threads subsystem
>> instead?
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
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
11:18 a.m.
The name issue wouldn't be quite so bad if we introduced some contract
for each subsystem to introduce a unique name for their pools, and maybe
another optional level of naming if they have more than one pool
"namespace" in a subsystem. Then a centralized view could be pretty
intuitive: "Thread Pools -> EJB -> ..."
On 10/20/2011 10:12 AM, Brian Stansberry wrote:
I struggled with that global view a bit over the last week.
I was thinking about approaching it as having it be a set of resources
in the threads subsystem that are basically just views onto the real
resource, which would exist in JCA, EJB etc.
That's not very satisfying. Leads to things like having to avoid
conflicts in pool names across subsystems. Plus it would be pretty hard
to implement.
I was noodling a bit this morning about separating the UI issue from the
core model a bit. The core model (in the threads subsystem) could just
provide resources addresses (and maybe a bit more metadata) about pools
configured elsewhere. The resources for pools would be consistent
throughout the model (e.g. a bounded-queue-thread-pool that supports
blocking would have the same attributes, ops, etc everywhere). The
console could use the info from the threads subsystem to discover all
the pool configs and then build a nice UI.
I suspect that's a problem for JON though. The CLI of course wouldn't be
able to produce a nice unified view, but IMHO that's not a critical problem.
On 10/20/11 8:16 AM, Jason Greene wrote:
> Right. What happened is we found out that having thread pools be global
> promotes sharing, which is usually an error since each subsystem needs
> specific configurations. We were planning on adding a global view that
> would see all the subsystems' thread pools so the administrator can
> easily identify which were in use however I don't think it was completed
> yet. Even though we neat them in the subsystem we still want them to be
> consistent.
>
> Sent from my iPhone
>
> On Oct 20, 2011, at 5:58 AM, Heiko Braun<hbraun(a)redhat.com
> <mailto:hbraun@redhat.com>> wrote:
>
>>
>>
>> no, but if possible they should rely on the default schema (xsd) for
>> defining inlined thread pool configurations.
>>
>> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
>>
>>> It seems that the latter defines pools that are used in
>>> /subsystem=ejb3/service=*
>>> Should they not be using thread pools defined in the threads subsystem
>>> instead?
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
- DML
12:15 p.m.
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
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, October 20, 2011 9:18:12 AM
Subject: Re: [jboss-as7-dev] Two thread pools sections in management
API
The name issue wouldn't be quite so bad if we introduced some
contract
for each subsystem to introduce a unique name for their pools, and
maybe
another optional level of naming if they have more than one pool
"namespace" in a subsystem. Then a centralized view could be pretty
intuitive: "Thread Pools -> EJB -> ..."
On 10/20/2011 10:12 AM, Brian Stansberry wrote:
> I struggled with that global view a bit over the last week.
>
> I was thinking about approaching it as having it be a set of
> resources
> in the threads subsystem that are basically just views onto the
> real
> resource, which would exist in JCA, EJB etc.
>
> That's not very satisfying. Leads to things like having to avoid
> conflicts in pool names across subsystems. Plus it would be pretty
> hard
> to implement.
>
> I was noodling a bit this morning about separating the UI issue
> from the
> core model a bit. The core model (in the threads subsystem) could
> just
> provide resources addresses (and maybe a bit more metadata) about
> pools
> configured elsewhere. The resources for pools would be consistent
> throughout the model (e.g. a bounded-queue-thread-pool that
> supports
> blocking would have the same attributes, ops, etc everywhere). The
> console could use the info from the threads subsystem to discover
> all
> the pool configs and then build a nice UI.
>
> I suspect that's a problem for JON though. The CLI of course
> wouldn't be
> able to produce a nice unified view, but IMHO that's not a critical
> problem.
>
> On 10/20/11 8:16 AM, Jason Greene wrote:
>> Right. What happened is we found out that having thread pools be
>> global
>> promotes sharing, which is usually an error since each subsystem
>> needs
>> specific configurations. We were planning on adding a global view
>> that
>> would see all the subsystems' thread pools so the administrator
>> can
>> easily identify which were in use however I don't think it was
>> completed
>> yet. Even though we neat them in the subsystem we still want them
>> to be
>> consistent.
>>
>> Sent from my iPhone
>>
>> On Oct 20, 2011, at 5:58 AM, Heiko Braun<hbraun(a)redhat.com
>> <mailto:hbraun@redhat.com>> wrote:
>>
>>>
>>>
>>> no, but if possible they should rely on the default schema (xsd)
>>> for
>>> defining inlined thread pool configurations.
>>>
>>> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
>>>
>>>> It seems that the latter defines pools that are used in
>>>> /subsystem=ejb3/service=*
>>>> Should they not be using thread pools defined in the threads
>>>> subsystem
>>>> instead?
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:32 p.m.
New 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
1:47 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
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
----- Original Message -----
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 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
2:02 p.m.
New subject: 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>
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 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
3:17 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
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
----- Original Message -----
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
> ----- Original Message -----
> > 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 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
> >
>
3:24 p.m.
New subject: 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
5 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
Do the configuration elements align with the default executor in JBoss Web, which is not
the JBoss Threads implementation?
Andy
----- Original Message -----
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.
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
5:16 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
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
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:27 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
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
5:41 p.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
Well, right now based on my testing, if you use the JBoss Threads executor, then you get a
performance degradation. It's not big, but its still there.
If you cannot set maxThreads, then I don't see how we can get the best possible
performance on our benchmark efforts. As you increase the injection rate, and run on the
large scale hardware we have planned, we will have to be able to set that.
So, I understand it can be abused, but so can a lot of settings. That's why we have
the administration and performance tuning guides (which I will be updating for EAP 6).
Andy
----- Original Message -----
From: "Jason T. Greene" <jason.greene(a)redhat.com>
To: "Brian Stansberry" <brian.stansberry(a)redhat.com>
Cc: "Andrig Miller" <anmiller(a)redhat.com>,
jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, October 20, 2011 3:27:58 PM
Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web
HTTP Threads
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
7:57 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
I agree with everything Andy said and absolutely needed to be able to set maxThreads in
our TorqueBox benchmarks. There may be some hypothetical reason I shouldn't need to
set maxThreads but in practice the performance before and after was night and day once a
hit a high enough concurrent client load. The defaults of 512 * # of CPUs was way too high
- 4096 http threads on my 8 CPU benchmark server kills performance and eats up way too
many resources.
Ben
On Oct 20, 2011, at 5:41 PM, Andrig Miller wrote:
Well, right now based on my testing, if you use the JBoss Threads
executor, then you get a performance degradation. It's not big, but its still there.
If you cannot set maxThreads, then I don't see how we can get the best possible
performance on our benchmark efforts. As you increase the injection rate, and run on the
large scale hardware we have planned, we will have to be able to set that.
So, I understand it can be abused, but so can a lot of settings. That's why we have
the administration and performance tuning guides (which I will be updating for EAP 6).
Andy
From: "Jason T. Greene" <jason.greene(a)redhat.com>
To: "Brian Stansberry" <brian.stansberry(a)redhat.com>
Cc: "Andrig Miller" <anmiller(a)redhat.com>, jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, October 20, 2011 3:27:58 PM
Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web HTTP Threads
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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:43 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote:
I agree with everything Andy said and absolutely needed to be able
to
set maxThreads in our TorqueBox benchmarks. There may be some
hypothetical reason I shouldn't need to set maxThreads but in practice
the performance before and after was night and day once a hit a high
enough concurrent client load. The defaults of 512 * # of CPUs was way
too high - 4096 http threads on my 8 CPU benchmark server kills
performance and eats up way too many resources.
If you want to run serious benchmarks and tune things, you should be
aware of how the server works, and what are the possibilities to solve
the problem.
The issue with reducing the amount of threads with the default java.io
connector (which is used unless the native libraries are installed) is
that it will, in most case, use a lot of its threads to do keepalive.
Keepalive is usually very important for real servers to give good user
experience, and also can help performance a lot. However, this is a
problem since, when running a benchmark with a specific client,
keepalive might not be used, or at least much less, and all threads
could actually be in the application, so 512 * n becomes far too high.
The problem goes away with the native libraries, since there is an
efficient way to handle keepalive, and all threads will be dedicated to
actually running the application. The default for the native connectors
is 32 * n threads. With native, a high number of threads is actually
directly detrimental to performance, since it has a lot of asynchronous
capabilities and needs a sync in one location to avoid crashing.
You have solutions, even with the java.io connector:
- Use an executor. This has all the configuration options you could
like, and the performance difference may not be measurable depending on
the application.
- Use a semaphore valve or filter, which will only allow a certain
amount of threads to concurrently enter specific parts of your
application. This allows much more fine tuning and could be a good
strategy.
As a compromise, I will propagate max-connections to maxThreads for the
java.io connector. This shouldn't hurt too much, and this corresponds
relatively well to the concept of connection count after all.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
10:13 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
On Oct 21, 2011, at 8:43 AM, Remy Maucherat wrote:
On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote:
> I agree with everything Andy said and absolutely needed to be able to
> set maxThreads in our TorqueBox benchmarks. There may be some
> hypothetical reason I shouldn't need to set maxThreads but in practice
> the performance before and after was night and day once a hit a high
> enough concurrent client load. The defaults of 512 * # of CPUs was way
> too high - 4096 http threads on my 8 CPU benchmark server kills
> performance and eats up way too many resources.
If you want to run serious benchmarks and tune things, you should be
aware of how the server works, and what are the possibilities to solve
the problem.
The issue with reducing the amount of threads with the default java.io
connector (which is used unless the native libraries are installed) is
that it will, in most case, use a lot of its threads to do keepalive.
Keepalive is usually very important for real servers to give good user
experience, and also can help performance a lot. However, this is a
problem since, when running a benchmark with a specific client,
keepalive might not be used, or at least much less, and all threads
could actually be in the application, so 512 * n becomes far too high.
The problem goes away with the native libraries, since there is an
efficient way to handle keepalive, and all threads will be dedicated to
actually running the application. The default for the native connectors
is 32 * n threads. With native, a high number of threads is actually
directly detrimental to performance, since it has a lot of asynchronous
capabilities and needs a sync in one location to avoid crashing.
Thanks for the detailed explanation on keepalives and the defaults.
You have solutions, even with the java.io connector:
- Use an executor. This has all the configuration options you could
like, and the performance difference may not be measurable depending on
the application.
- Use a semaphore valve or filter, which will only allow a certain
amount of threads to concurrently enter specific parts of your
application. This allows much more fine tuning and could be a good
strategy.
As a compromise, I will propagate max-connections to maxThreads for the
java.io connector. This shouldn't hurt too much, and this corresponds
relatively well to the concept of connection count after all.
Thanks!
--
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
10:37 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
----- Original Message -----
From: "Benjamin Browning" <bbrowning(a)redhat.com>
To: "jboss-as7-dev(a)lists.jboss.org Development"
<jboss-as7-dev(a)lists.jboss.org>
Sent: Friday, October 21, 2011 8:13:43 AM
Subject: Re: [jboss-as7-dev] Controlling Maximum Number of JBoss Web
HTTP Threads
On Oct 21, 2011, at 8:43 AM, Remy Maucherat wrote:
> On Fri, 2011-10-21 at 07:57 -0400, Benjamin Browning wrote:
>> I agree with everything Andy said and absolutely needed to be able
>> to
>> set maxThreads in our TorqueBox benchmarks. There may be some
>> hypothetical reason I shouldn't need to set maxThreads but in
>> practice
>> the performance before and after was night and day once a hit a
>> high
>> enough concurrent client load. The defaults of 512 * # of CPUs was
>> way
>> too high - 4096 http threads on my 8 CPU benchmark server kills
>> performance and eats up way too many resources.
>
> If you want to run serious benchmarks and tune things, you should
> be
> aware of how the server works, and what are the possibilities to
> solve
> the problem.
>
> The issue with reducing the amount of threads with the default
> java.io
> connector (which is used unless the native libraries are installed)
> is
> that it will, in most case, use a lot of its threads to do
> keepalive.
> Keepalive is usually very important for real servers to give good
> user
> experience, and also can help performance a lot. However, this is a
> problem since, when running a benchmark with a specific client,
> keepalive might not be used, or at least much less, and all threads
> could actually be in the application, so 512 * n becomes far too
> high.
> The problem goes away with the native libraries, since there is an
> efficient way to handle keepalive, and all threads will be
> dedicated to
> actually running the application. The default for the native
> connectors
> is 32 * n threads. With native, a high number of threads is
> actually
> directly detrimental to performance, since it has a lot of
> asynchronous
> capabilities and needs a sync in one location to avoid crashing.
Thanks for the detailed explanation on keepalives and the defaults.
In terms of keep alives, I had opened a JIRA to add the maxKeepAlive parameter to the
schema and expose that for tuning. Is there an issue you have with exposing that? It's
another key tuning parameter for benchmarking.
Andy
>
> You have solutions, even with the java.io connector:
> - Use an executor. This has all the configuration options you could
> like, and the performance difference may not be measurable
> depending on
> the application.
> - Use a semaphore valve or filter, which will only allow a certain
> amount of threads to concurrently enter specific parts of your
> application. This allows much more fine tuning and could be a good
> strategy.
>
> As a compromise, I will propagate max-connections to maxThreads for
> the
> java.io connector. This shouldn't hurt too much, and this
> corresponds
> relatively well to the concept of connection count after all.
Thanks!
>
> --
> 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
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
4 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
On Thu, 2011-10-20 at 14:24 -0500, Brian Stansberry wrote:
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/...
I don't like it, since it should be possible to have all connectors
share one thread pool, or each connector use its own thread pool, etc.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
3:58 a.m.
New subject: 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.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc
8 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
That's fine - I'll add it ;)
On Oct 21, 2011, at 3:58 AM, Remy Maucherat wrote:
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.
--
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
10:32 a.m.
New subject: Controlling Maximum Number of JBoss Web HTTP Threads
----- 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
1:02 p.m.
HornetQ has a similar situation. Looking at the internals, it seemed HQ
was using a pretty generic thread pool, so if there was a hook so the AS
could inject one we could use the AS standard configs in the messaging
subsystem.
On 10/20/11 11:15 AM, 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
------------------------------------------------------------------------
*From: *"David M. Lloyd" <david.lloyd(a)redhat.com>
*To: *jboss-as7-dev(a)lists.jboss.org
*Sent: *Thursday, October 20, 2011 9:18:12 AM
*Subject: *Re: [jboss-as7-dev] Two thread pools sections in
management API
The name issue wouldn't be quite so bad if we introduced some contract
for each subsystem to introduce a unique name for their pools, and
maybe
another optional level of naming if they have more than one pool
"namespace" in a subsystem. Then a centralized view could be pretty
intuitive: "Thread Pools -> EJB -> ..."
On 10/20/2011 10:12 AM, Brian Stansberry wrote:
> I struggled with that global view a bit over the last week.
>
> I was thinking about approaching it as having it be a set of
resources
> in the threads subsystem that are basically just views onto the real
> resource, which would exist in JCA, EJB etc.
>
> That's not very satisfying. Leads to things like having to avoid
> conflicts in pool names across subsystems. Plus it would be
pretty hard
> to implement.
>
> I was noodling a bit this morning about separating the UI issue
from the
> core model a bit. The core model (in the threads subsystem) could
just
> provide resources addresses (and maybe a bit more metadata) about
pools
> configured elsewhere. The resources for pools would be consistent
> throughout the model (e.g. a bounded-queue-thread-pool that supports
> blocking would have the same attributes, ops, etc everywhere). The
> console could use the info from the threads subsystem to discover all
> the pool configs and then build a nice UI.
>
> I suspect that's a problem for JON though. The CLI of course
wouldn't be
> able to produce a nice unified view, but IMHO that's not a
critical problem.
>
> On 10/20/11 8:16 AM, Jason Greene wrote:
>> Right. What happened is we found out that having thread pools be
global
>> promotes sharing, which is usually an error since each subsystem
needs
>> specific configurations. We were planning on adding a global
view that
>> would see all the subsystems' thread pools so the administrator can
>> easily identify which were in use however I don't think it was
completed
>> yet. Even though we neat them in the subsystem we still want
them to be
>> consistent.
>>
>> Sent from my iPhone
>>
>> On Oct 20, 2011, at 5:58 AM, Heiko Braun<hbraun(a)redhat.com
>> <mailto:hbraun@redhat.com>> wrote:
>>
>>>
>>>
>>> no, but if possible they should rely on the default schema
(xsd) for
>>> defining inlined thread pool configurations.
>>>
>>> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
>>>
>>>> It seems that the latter defines pools that are used in
>>>> /subsystem=ejb3/service=*
>>>> Should they not be using thread pools defined in the threads
subsystem
>>>> instead?
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>>
jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
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
1:38 p.m.
Yep, I forgot about that one. In fact, I think the default configuration is to just create
threads as needed, and then the go away. If you specify the thread pool parameter than it
will pool and keep them around.
Andy
----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, October 20, 2011 11:02:25 AM
Subject: Re: [jboss-as7-dev] Two thread pools sections in management
API
HornetQ has a similar situation. Looking at the internals, it seemed
HQ
was using a pretty generic thread pool, so if there was a hook so the
AS
could inject one we could use the AS standard configs in the
messaging
subsystem.
On 10/20/11 11:15 AM, 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
>
> ------------------------------------------------------------------------
>
> *From: *"David M. Lloyd" <david.lloyd(a)redhat.com>
> *To: *jboss-as7-dev(a)lists.jboss.org
> *Sent: *Thursday, October 20, 2011 9:18:12 AM
> *Subject: *Re: [jboss-as7-dev] Two thread pools sections in
> management API
>
> The name issue wouldn't be quite so bad if we introduced some
> contract
> for each subsystem to introduce a unique name for their pools, and
> maybe
> another optional level of naming if they have more than one pool
> "namespace" in a subsystem. Then a centralized view could be pretty
> intuitive: "Thread Pools -> EJB -> ..."
>
> On 10/20/2011 10:12 AM, Brian Stansberry wrote:
> > I struggled with that global view a bit over the last week.
> >
> > I was thinking about approaching it as having it be a set of
> resources
> > in the threads subsystem that are basically just views onto the
> > real
> > resource, which would exist in JCA, EJB etc.
> >
> > That's not very satisfying. Leads to things like having to avoid
> > conflicts in pool names across subsystems. Plus it would be
> pretty hard
> > to implement.
> >
> > I was noodling a bit this morning about separating the UI issue
> from the
> > core model a bit. The core model (in the threads subsystem) could
> just
> > provide resources addresses (and maybe a bit more metadata) about
> pools
> > configured elsewhere. The resources for pools would be consistent
> > throughout the model (e.g. a bounded-queue-thread-pool that
> > supports
> > blocking would have the same attributes, ops, etc everywhere).
> > The
> > console could use the info from the threads subsystem to discover
> > all
> > the pool configs and then build a nice UI.
> >
> > I suspect that's a problem for JON though. The CLI of course
> wouldn't be
> > able to produce a nice unified view, but IMHO that's not a
> critical problem.
> >
> > On 10/20/11 8:16 AM, Jason Greene wrote:
> >> Right. What happened is we found out that having thread pools be
> global
> >> promotes sharing, which is usually an error since each subsystem
> needs
> >> specific configurations. We were planning on adding a global
> view that
> >> would see all the subsystems' thread pools so the administrator
> >> can
> >> easily identify which were in use however I don't think it was
> completed
> >> yet. Even though we neat them in the subsystem we still want
> them to be
> >> consistent.
> >>
> >> Sent from my iPhone
> >>
> >> On Oct 20, 2011, at 5:58 AM, Heiko Braun<hbraun(a)redhat.com
> >> <mailto:hbraun@redhat.com>> wrote:
> >>
> >>>
> >>>
> >>> no, but if possible they should rely on the default schema
> (xsd) for
> >>> defining inlined thread pool configurations.
> >>>
> >>> On Oct 20, 2011, at 12:50 PM, David Bosschaert wrote:
> >>>
> >>>> It seems that the latter defines pools that are used in
> >>>> /subsystem=ejb3/service=*
> >>>> Should they not be using thread pools defined in the threads
> subsystem
> >>>> instead?
> >>>
> >>> _______________________________________________
> >>> jboss-as7-dev mailing list
> >>>
jboss-as7-dev@lists.jboss.org<mailto:jboss-as7-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
> >>
> >> _______________________________________________
> >> jboss-as7-dev mailing list
> >> jboss-as7-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
>
>
> --
> - DML
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> 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
4569
days inactive
4570
days old
24 comments
9 participants
participants (9)
-
Andrig Miller -
Benjamin Browning -
Brian Stansberry -
David Bosschaert -
David M. Lloyd -
Heiko Braun -
Jason Greene -
Jason T. Greene -
Remy Maucherat