Have you tried calling prestartCoreThread() or prestartAllCoreThreads()
on the ThreadPoolExecutor? From what I remember in the code, we're not
using making that call.
Jeanfrancois Arcand wrote:
> Salut,
>
> Oleksiy Stashok wrote:
>> Hi,
>>
>>> yesterday I've created a new branch that build using the
>>> Pipeline(ThreadPool) API we used until 1.8.6. Starting with 1.9.0,
>>> we started using ExecutorService and so far we have suffered many
>>> issues, mostly configuration wise. Internally, we have done a lot of
>>> benchmarks and we don't see any improvement with
>>> ExecutorServices...but we do see many regressions, mostly related to
>>> the number of threads created by default. So far the workaround is
>>> to set the core == maxThreads to have the same behavior/good
>>> performance like we had with 1.8.6.
>> IMHO this was fixed by Bongjae in the latest DefaultThreadPool. If we
>> will use Pipeline together with Leader-follower - then we still need
>> to be careful with the configuration, as same or similar
>> thread-starving issues may happen.
>
> No it hasn't...the JRuby benchmark still fails because of the queue
> gets full before a Thresd is created.
>
>
>>
>>> Take a look at the branch:
>>>
>>> * branches/pipeline
>>>
>>> I would like to start a discussion on the possible removal.
>>> Personally I don't like the current configuration issues, and also
>>> the fact that we don't get any performance improvement using
>>> ExecutorServices. But I'm open to discuss and see what peoples thinks.
>> If we will improve performance - then probably there will be no
>> arguments :))
>
> Right but so far we regressed instead :-)
>
> A+
>
> -- Jeanfrancois
>
>
>>
>> WBR,
>> Alexey.
>>
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>> ---------------------------------------------------------------------
>>> 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
>