>>
>>> 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.
IMHO JRuby still uses old DefaultThreadPool, the new one is still not
integrated to Glassfish.
>
>
>>> 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 :-)
It would be great to see the difference! Everything same, except
thread pools. Hope Scott will be able to do such measurement.
Thanks.
WBR,
Alexey.
>
> 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
>