The changes are merged on trunk.
WBR,
Alexey.
On Dec 2, 2008, at 2:40 , Jeanfrancois Arcand wrote:
> Salut,
>
> I"ve moved the code under branches/1.9.0-executors so it doesn't
> clash with trunk when you deploy.
>
> Thanks!
>
> -- Jeanfrancois
>
> Oleksiy Stashok wrote:
>> The migration is completed, and available in SVN repository using
>> tag: Grizzly 1.9.0-sandbox
>> Most of the API: methods, elements, which had "pipeline" as part of
>> a name, now renamed to "threadPool". ExecutorService is used as
>> general thread pool interface.
>> Grizzly provides default implementation called DefaultThreadPool,
>> which extends ThreadPoolExecutor.
>> Will appreciate your feedback.
>> Thanks.
>> WBR,
>> Alexey.
>> On Nov 28, 2008, at 0:23 , charlie hunt wrote:
>>> If you would like to do some performance testing in our internal
>>> performance lab with an UltraSPARC T2, single socket (code name
>>> Niagara) or 4 socket (code name Batoka), let me know.
>>>
>>> Those machines are pretty impressive when it comes to "web"
>>> workloads.
>>>
>>> charlie ...
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> gustav trede wrote:
>>>>>
>>>>>
>>>>> 2008/11/27 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com
>>>>> >>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Alexey and I thinks that it might be time to drop the Pipeline
>>>>> interface and directly expose Executors. In order to do that, we
>>>>> will break backward compatibility with 1.8.x for application
>>>>> that
>>>>> were using this interface. I do suspect we will not break a
>>>>> lot of
>>>>> application, but just to make sure, I would like to propose the
>>>>> following:
>>>>>
>>>>> (1) Assuming we don't see any performance regression (I've never
>>>>> trusted the Concurrent's thread pool and demonstrated many
>>>>> time our
>>>>> was faster), we switch to Executors
>>>>>
>>>>> (2) If a critical bug is found with 1.8.x users, we continue
>>>>> maintaining the 1.8.x branch so peoples doesn't have to change
>>>>> anything
>>>>>
>>>>> Alexey has a patch that I will try and test to make sure no
>>>>> performance regressions occurs.
>>>>>
>>>>> What peoples think?
>>>>>
>>>>> A+
>>>>>
>>>>>
>>>>>
>>>>> sounds good.
>>>>> lets replace the default executor in my patch in cometengine
>>>>> with grizzlys executor since its faster ?
>>>>
>>>> We don't know yet if it is faster or not so for now, I would keep
>>>> you patch as it is. Give us a couple of days :-)
>>>>
>>>> A+
>>>>
>>>> --Jeanfrancois
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>> <mailto: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
>