Hi,
after latest thread pool related questions, I really start to be upset
with DefaultThreadPool implementation, which is based on JDK
ThreadPoolExecutor.
Really, thread pool, which prefers to add tasks to queue until it gets
full, IMHO, doesn't look useful for us.
We do have another implementation PipelineThreadPool (called Pipeline
because of former Grizzly 1.x thread pool API), which prefers to
create new worker, until possible, and then start to add tasks to queue.
May be we can do some "refactoring" and make PipelineThreadPool
default one?
What do you think?
WBR,
Alexey.
On May 7, 2009, at 16:10 , Bongjae Chang wrote:
> 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
>>
>>
>>
>>