Two thread pools sections in management API

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Two thread pools sections in management API

David Bosschaert
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
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Heiko Braun


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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Jason T. Greene
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Brian Stansberry
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 <[hidden email]
> <mailto:[hidden email]>> 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
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

David Lloyd-2
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<[hidden email]
>> <mailto:[hidden email]>>  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
>>> [hidden email]<mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Andrig Miller
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" <[hidden email]>
To: [hidden email]
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<[hidden email]
>> <mailto:[hidden email]>>  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
>>> [hidden email]<mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
- DML
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Controlling Maximum Number of JBoss Web HTTP Threads

Benjamin Browning
<base href="x-msg://155/">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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Brian Stansberry
In reply to this post by Andrig Miller
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" <[hidden email]>
>     *To: *[hidden email]
>     *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<[hidden email]
>      >> <mailto:[hidden email]>> 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
>      >>> [hidden email]<mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>
>      >>
>      >> _______________________________________________
>      >> jboss-as7-dev mailing list
>      >> [hidden email]
>      >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >
>      >
>
>
>     --
>     - DML
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Two thread pools sections in management API

Andrig Miller
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


From: "Brian Stansberry" <[hidden email]>
To: [hidden email]
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" <[hidden email]>
>     *To: *[hidden email]
>     *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<[hidden email]
>      >> <mailto:[hidden email]>> 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
>      >>> [hidden email]<mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >>
>      >>
>      >> _______________________________________________
>      >> jboss-as7-dev mailing list
>      >> [hidden email]
>      >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>      >
>      >
>
>
>     --
>     - DML
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Andrig Miller
In reply to this post by Benjamin Browning
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" <[hidden email]>
To: "Andrig Miller" <[hidden email]>
Cc: "[hidden email] Development" <[hidden email]>
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Benjamin Browning
<base href="x-msg://184/">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" <[hidden email]>
To: "Andrig Miller" <[hidden email]>
Cc: "[hidden email] Development" <[hidden email]>
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Andrig Miller
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" <[hidden email]>
To: "Andrig Miller" <[hidden email]>
Cc: "[hidden email] Development" <[hidden email]>
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" <[hidden email]>
To: "Andrig Miller" <[hidden email]>
Cc: "[hidden email] Development" <[hidden email]>
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Brian Stansberry
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" <[hidden email]>
>     *To: *"Andrig Miller" <[hidden email]>
>     *Cc: *"[hidden email] Development"
>     <[hidden email]>
>     *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" <[hidden email]
>             <mailto:[hidden email]>>
>             *To:*"Andrig Miller" <[hidden email]
>             <mailto:[hidden email]>>
>             *Cc:*"[hidden email]
>             <mailto:[hidden email]>Development"
>             <[hidden email]
>             <mailto:[hidden email]>>
>             *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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Andrig Miller
Do the configuration elements align with the default executor in JBoss Web, which is not the JBoss Threads implementation?

Andy


From: "Brian Stansberry" <[hidden email]>
To: [hidden email]
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" <[hidden email]>
>     *To: *"Andrig Miller" <[hidden email]>
>     *Cc: *"[hidden email] Development"
>     <[hidden email]>
>     *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" <[hidden email]
>             <mailto:[hidden email]>>
>             *To:*"Andrig Miller" <[hidden email]
>             <mailto:[hidden email]>>
>             *Cc:*"[hidden email]
>             <mailto:[hidden email]>Development"
>             <[hidden email]
>             <mailto:[hidden email]>>
>             *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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Brian Stansberry
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" <[hidden email]>
>     *To: *[hidden email]
>     *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" <[hidden email]>
>      > *To: *"Andrig Miller" <[hidden email]>
>      > *Cc: *"[hidden email] Development"
>      > <[hidden email]>
>      > *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" <[hidden email]
>      > <mailto:[hidden email]>>
>      > *To:*"Andrig Miller" <[hidden email]
>      > <mailto:[hidden email]>>
>      > *Cc:*"[hidden email]
>      > <mailto:[hidden email]>Development"
>      > <[hidden email]
>      > <mailto:[hidden email]>>
>      > *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
>      > [hidden email]
>      > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>     --
>     Brian Stansberry
>     Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email]
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

jtgreene
Administrator
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"<[hidden email]>
>>      *To: *[hidden email]
>>      *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"<[hidden email]>
>>       >  *To: *"Andrig Miller"<[hidden email]>
>>       >  *Cc: *"[hidden email] Development"
>>       >  <[hidden email]>
>>       >  *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"<[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *To:*"Andrig Miller"<[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *Cc:*"[hidden email]
>>       >  <mailto:[hidden email]>Development"
>>       >  <[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *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
>>       >  [hidden email]
>>       >  https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email]
>>      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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Andrig Miller
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" <[hidden email]>
To: "Brian Stansberry" <[hidden email]>
Cc: "Andrig Miller" <[hidden email]>, [hidden email]
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"<[hidden email]>
>>      *To: *[hidden email]
>>      *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"<[hidden email]>
>>       >  *To: *"Andrig Miller"<[hidden email]>
>>       >  *Cc: *"[hidden email] Development"
>>       >  <[hidden email]>
>>       >  *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"<[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *To:*"Andrig Miller"<[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *Cc:*"[hidden email]
>>       >  <mailto:[hidden email]>Development"
>>       >  <[hidden email]
>>       >  <mailto:[hidden email]>>
>>       >  *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
>>       >  [hidden email]
>>       >  https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email]
>>      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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Rémy Maucherat
In reply to this post by Andrig Miller
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 <[hidden email]>
Red Hat Inc

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Rémy Maucherat
In reply to this post by Brian Stansberry
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/docs/schema/jboss-as-jca_1_0.xsd#L120

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 <[hidden email]>
Red Hat Inc

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Controlling Maximum Number of JBoss Web HTTP Threads

Benjamin Browning
In reply to this post by Andrig Miller
<base href="x-msg://34/">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" <[hidden email]>
To: "Brian Stansberry" <[hidden email]>
Cc: "Andrig Miller" <[hidden email]>, [hidden email]
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"<[hidden email]>
>>      *To: [hidden email]
>>      *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"<[hidden email]>
>>       >  *To: *"Andrig Miller"<[hidden email]>
>>       >  *Cc: *"[hidden email] Development"
>>       >  <[hidden email]>
>>       >  *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"<[hidden email]
>>       >  <[hidden email]>>
>>       >  *To:*"Andrig Miller"<[hidden email]
>>       >  <[hidden email]>>
>>       >  *Cc:*"[hidden email]
>>       >  <[hidden email]>Development"
>>       >  <[hidden email]
>>       >  <[hidden email]>>
>>       >  *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
>>       >  [hidden email]
>>       >  https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>      --
>>      Brian Stansberry
>>      Principal Software Engineer
>>      JBoss by Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      [hidden email]
>>      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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12