Salut,
Oleksiy Stashok wrote:
> 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?
I agree. Rama also observed some issue with the current
DefaultThreadPool. I think bringing back the old logic could help.
A+
--Jeanfrancois
>
> 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
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>