Thread pool question in AS 7

[jacobmarcus20]

Hi,

One thing I noticed in the tests I did with AS 7 is that threads created hang around. They don't seem to go away after they are idle and not doing anything for a very long time. Ideally I would like to have a smaller number in this ready and waiting state. My application has bursty traffic. So I expect additional threads to be created on a need basis as long as they are < max-connections specified at the connector level. But I expect these extra threads to be killed/removed after the burst and have only a smaller number remaining in the ready state.

Here is an example config I used for testing purposes.

<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" max-connections="20"/>

Once 20 threads are created, all 20 of them remain.

I understand that I can use an executor configuration like this to get close to what I want. But  am reading in some messages that using the executor may impact throughput/performance.

<subsystem xmlns="urn:jboss:domain:threads:1.1">

            <bounded-queue-thread-pool name="test" allow-core-timeout="false">

                <core-threads count="5"/>

                <queue-length count="1"/>

                <max-threads count="20"/>

                <keepalive-time time="10" unit="seconds"/>

            </bounded-queue-thread-pool>

        </subsystem>

In this I am able to keep 5 threads in a waiting state. Another 15 can be created on demand and discarded after use. I gave a small queue length as I found that a larger queue seemed to make the server hesitate to create additional threads and thus impacted throughput.

1) Is there anyway to achieve what I am looking for without using an executor in AS 7?

2)  I like the queue concept but would like it to come into play after the max-threads have reached. I saw documentation of the org.apache.catalina.core.StandardThreadExecutor in jboss 7?

Thanks,

Jacob

[taras.tielkes]

We have a traffic pattern with occasional peaks.

We've set the max-connections to 2048, but having all those threads hang around does not make sense.

In fact, it hurts GC performance, as the collector needs to iterate the stacks of all JVM threads as part of determining the set of GC roots.

As such, I'd like to know the anwer to this as well.

I would like to use a configuration that is as close as possible to the default, with the only change that we would like inactive/idle threads to stop eventually.

What would be the explicit xml equivalent of the (implicit) default thread pool configuration?

[jfclere]

you need an executor to do that.

[kclair-rei]

Can you suggest an executor configuration that would be most like the default with the difference that a keepalive-time is set?