Hi Jeanfrancois,
Thank you for your patch.
I saw your patch code now. But I think that max-pool-size's modification is maybe not enough because java.util.concurrent.ThreadPoolExecutor only allows thread's increment when its queue is full.
(Of course, when current thread count is not under core-pool-size)
So I think that core-pool-size is also modified if Grizzly still uses java.util.concurrent.ThreadPoolExecutor without thread increment's policy.
Thanks.
--
Bongjae Chang
----- Original Message -----
From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM>
To: <dev_at_grizzly.dev.java.net>
Sent: Thursday, May 07, 2009 10:52 PM
Subject: Re: Default thread pool size issue
> Salut,
>
> I've re-opened
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=566
>
> And fixed the issue. Thanks Bongjae!
>
> -- Jeanfrancois
>
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> Justin Lee wrote:
>>> That's actually what I thought when I read his email, too. Makes sense.
>>> Should that formula be used in grizzly-config, too?
>>
>> I would say yes. Look at Controller.autoConfigureCore() logic.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> Bongjae Chang wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> When I tested TCP layer recently in grizzly, I met some problems of
>>>>> Cotroller's initialization which had been not occurred before.
>>>>>
>>>>> Here is some examples
>>>>> - ControllerStateListener's onReady() was not invoked in main Controller.
>>>>> - When I tried to connect a tcp connection, maybe timeout was occurred
>>>>> and I failed to send the packet to the remote server.
>>>>> - etc...
>>>>>
>>>>> When I debugged this problem, I could know that this was the
>>>>> side-effect of "Auto-configure the number of ReaderController based on
>>>>> OS/Core or the machine" issue(svn rev.3088, issue #566).
>>>>>
>>>>> I could know that 4 ReaderControllers was initialized when I had tested
>>>>> this on 4 CPUs. Before issue #566 was committed, ReaderController was
>>>>> not used because default read-thread-count was 0.
>>>>>
>>>>> As you know, default thread pool is shared between main Controller and
>>>>> ReaderController and default thread pool's core size and max size are 5.
>>>>>
>>>>> Then if gizzly is used on 3~4 more CPUs, I think that many tasks of
>>>>> grizzly can not be executing but queueing in thread pool executor.
>>>>>
>>>>> So, I think that default thread pool size is not enough and default
>>>>> size should also be configured automatically or at least warning message
>>>>> should be logged if the minimum thread's number for initialization was
>>>>> not guaranteed.
>>>>>
>>>>> When I tested this on my thread pool which had 11 core size and 11 max
>>>>> size, I could confim no problems.
>>>>>
>>>> Completely agree. I think the number of threads in that case should be
>>>> core * default value. What do you think?
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> Bongjae Chang
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
>