You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2007/10/09 04:18:12 UTC
jetty jee5 assembly broken in branches/2.0
Folks,
For last few days the 2.0 tests have been timing out. The server just
keeps logging the following exceptions:
20:56:32,531 WARN [log] dispatch failed!
20:56:32,531 WARN [JettyThreadPool]
java.util.concurrent.RejectedExecutionException
20:56:32,531 WARN [log] dispatch failed!
20:56:32,531 WARN [JettyThreadPool]
java.util.concurrent.RejectedExecutionException
The requests are not handled and tests just time out.
I tracked this problem down to the poolSize in DefaultThreadPool
gbean. It was recently changed from 500 to 150. Everything works fine
with 500 but breaks with 150. That's at least what I see.
I would think that changing the pool size would have no effect on this
functionality so something is definitely not setup right. Also, I
believe the same problem exists in branches/2.0.2.
Any ideas/thoughts?
Jarek
Re: jetty jee5 assembly broken in branches/2.0
Posted by Matt Hogstrom <ma...@hogstrom.org>.
Disabling AJP by default makes a lot of sense. Users that are
interested will seek it out.
I think 25 threads per core as a default makes sense as a good
starting point. Assuming most people would run a 4-way for
"production" a default in the thread pool like 100 is a good
starting point.
I'm taking a stab at the core pool size which I think should 25 with
a max of 100.
On Oct 17, 2007, at 11:03 AM, Jarek Gawor wrote:
> Any more thoughts on this, especially on the current thread pool
> behavior?
>
> Jarek
>
> On 10/9/07, Jarek Gawor <jg...@gmail.com> wrote:
>> On 10/9/07, Kevan Miller <ke...@gmail.com> wrote:
>>>
>>> Jarek,
>>> Thanks for tracking this down.
>>>
>>> 50 threads per connector seems like overkill to me. It's
>>> dependent on
>>> application behavior. So, hard to predict... But I would consider
>>> lowering the per connector thread count. I won't argue with
>>> increasing the thread pool size, however...
>>>
>>> I also think these WARN messages are a bit less useful than they
>>> ought to be...
>>
>> What number should we lower it to? 25? 30? Maybe we should consider
>> also having the AJP connector be disabled by default? It consumes
>> lots
>> of threads but probably is not used most of the time.
>>
>> Another thing I noticed that in ThreadPool.java the
>> ThreadPoolExecutor
>> is configured with the same corePoolSize and maximumPoolSize. Which
>> means (if I'm reading the documentation right) that everytime you
>> submit a task to execute a new thread will be created until
>> maximumPoolSize threads are created. Also, setting corePoolSize ==
>> maximumPoolSize means that the idle threads will not be reclaimed. So
>> basically, we are not reusing threads until we have maximumPoolSize
>> threads running and we will never reclaim any idle threads. This
>> seems
>> pretty bad to me especially since our pool is now set to 500.
>>
>> Jarek
>>
>
Re: jetty jee5 assembly broken in branches/2.0
Posted by Jarek Gawor <jg...@gmail.com>.
Any more thoughts on this, especially on the current thread pool behavior?
Jarek
On 10/9/07, Jarek Gawor <jg...@gmail.com> wrote:
> On 10/9/07, Kevan Miller <ke...@gmail.com> wrote:
> >
> > Jarek,
> > Thanks for tracking this down.
> >
> > 50 threads per connector seems like overkill to me. It's dependent on
> > application behavior. So, hard to predict... But I would consider
> > lowering the per connector thread count. I won't argue with
> > increasing the thread pool size, however...
> >
> > I also think these WARN messages are a bit less useful than they
> > ought to be...
>
> What number should we lower it to? 25? 30? Maybe we should consider
> also having the AJP connector be disabled by default? It consumes lots
> of threads but probably is not used most of the time.
>
> Another thing I noticed that in ThreadPool.java the ThreadPoolExecutor
> is configured with the same corePoolSize and maximumPoolSize. Which
> means (if I'm reading the documentation right) that everytime you
> submit a task to execute a new thread will be created until
> maximumPoolSize threads are created. Also, setting corePoolSize ==
> maximumPoolSize means that the idle threads will not be reclaimed. So
> basically, we are not reusing threads until we have maximumPoolSize
> threads running and we will never reclaim any idle threads. This seems
> pretty bad to me especially since our pool is now set to 500.
>
> Jarek
>
Re: jetty jee5 assembly broken in branches/2.0
Posted by Jarek Gawor <jg...@gmail.com>.
On 10/9/07, Kevan Miller <ke...@gmail.com> wrote:
>
> Jarek,
> Thanks for tracking this down.
>
> 50 threads per connector seems like overkill to me. It's dependent on
> application behavior. So, hard to predict... But I would consider
> lowering the per connector thread count. I won't argue with
> increasing the thread pool size, however...
>
> I also think these WARN messages are a bit less useful than they
> ought to be...
What number should we lower it to? 25? 30? Maybe we should consider
also having the AJP connector be disabled by default? It consumes lots
of threads but probably is not used most of the time.
Another thing I noticed that in ThreadPool.java the ThreadPoolExecutor
is configured with the same corePoolSize and maximumPoolSize. Which
means (if I'm reading the documentation right) that everytime you
submit a task to execute a new thread will be created until
maximumPoolSize threads are created. Also, setting corePoolSize ==
maximumPoolSize means that the idle threads will not be reclaimed. So
basically, we are not reusing threads until we have maximumPoolSize
threads running and we will never reclaim any idle threads. This seems
pretty bad to me especially since our pool is now set to 500.
Jarek
Re: jetty jee5 assembly broken in branches/2.0
Posted by Kevan Miller <ke...@gmail.com>.
On Oct 9, 2007, at 12:59 AM, Jarek Gawor wrote:
> Oh, I think I know what's going on. Jetty is configured with 3
> connectors. Each connector is configured with 50 threads. So by the
> time the server starts up all the threads in the pool are taken..
> Looks like in Jetty we must set the thread pool size to > 150.
Jarek,
Thanks for tracking this down.
50 threads per connector seems like overkill to me. It's dependent on
application behavior. So, hard to predict... But I would consider
lowering the per connector thread count. I won't argue with
increasing the thread pool size, however...
I also think these WARN messages are a bit less useful than they
ought to be...
--kevan
Re: jetty jee5 assembly broken in branches/2.0
Posted by Jarek Gawor <jg...@gmail.com>.
Oh, I think I know what's going on. Jetty is configured with 3
connectors. Each connector is configured with 50 threads. So by the
time the server starts up all the threads in the pool are taken..
Looks like in Jetty we must set the thread pool size to > 150.
Jarek
On 10/8/07, Jarek Gawor <jg...@gmail.com> wrote:
> Folks,
>
> For last few days the 2.0 tests have been timing out. The server just
> keeps logging the following exceptions:
>
> 20:56:32,531 WARN [log] dispatch failed!
> 20:56:32,531 WARN [JettyThreadPool]
> java.util.concurrent.RejectedExecutionException
> 20:56:32,531 WARN [log] dispatch failed!
> 20:56:32,531 WARN [JettyThreadPool]
> java.util.concurrent.RejectedExecutionException
>
> The requests are not handled and tests just time out.
>
> I tracked this problem down to the poolSize in DefaultThreadPool
> gbean. It was recently changed from 500 to 150. Everything works fine
> with 500 but breaks with 150. That's at least what I see.
>
> I would think that changing the pool size would have no effect on this
> functionality so something is definitely not setup right. Also, I
> believe the same problem exists in branches/2.0.2.
>
> Any ideas/thoughts?
>
> Jarek
>