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
>