[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR : JDK-8141591 - javax/management/remote/mandatory/threads/ExecutorTest.java fails
From:       Daniel Fuchs <daniel.fuchs () oracle ! com>
Date:       2016-11-21 9:56:57
Message-ID: 715872ac-2d13-2282-ffdf-e102e0478926 () oracle ! com
[Download RAW message or body]

Hi Harsha,

I'm still unsure that creating a new executor is the
right solution, but we can give it a try...

good to go.

best regards,

-- daniel

On 17/11/16 13:14, Harsha Wardhana B wrote:
> Hello,
>
> Gentle reminder !!
>
> -Harsha
>
>
> On Tuesday 15 November 2016 02:16 PM, Harsha Wardhana B wrote:
>>
>> Hello,
>>
>> Please review below webrev incorporating Daniel's comments.
>>
>> http://cr.openjdk.java.net/~hb/8141591/webrev.01/
>>
>> Regards
>> Harsha
>>
>> On Monday 14 November 2016 04:14 PM, Daniel Fuchs wrote:
>>> On 14/11/16 06:57, Harsha Wardhana B wrote:
>>>>>> Well, that will not cover the case where user shuts down executor but
>>>>>> keeps the client/server alive. So we will need a executor that can
>>>>>> keep
>>>>>> notif system running as well as do clean-up if client/server is
>>>>>> closed.
>>>>>
>>>>> It's OK to continue in order to do clean up and
>>>>> shutdown gracefully. It seems wrong to keep going afterwards
>>>>> as if nothing had happened though (in the case the
>>>>> user shuts the supplied executor down).
>>>> With current changes, we do continue to carry on with linear executor.
>>>> If the user wants to shutdown the system, he can always do it by
>>>> shutting down client and server along with executor. If he shuts down
>>>> executor but not client/server, it may be safe to assume that he wants
>>>> the system to be up and running. It may not be appropriate to assume
>>>> user wants to shutdown notif system just because he shutdown executor.
>>>
>>> Well, it may also not be appropriate to invoke a user provided callback
>>> on another executor than the one provided by the user.
>>> If the user provides an executor, we must assume he has good
>>> reasons to do so.
>>> I'm not hard set to opposing to what you propose, but it makes me
>>> feel uncomfortable.
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]