Mailing-List: contact dev-help@reef.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@reef.apache.org
Date: Tue, 19 Jul 2016 06:12:20 +0000 (UTC)
From: "Sanha Lee (JIRA)" <jira@apache.org>
To: dev@reef.apache.org
Message-ID: <JIRA.12904268.1444677015000.68796.1468908740451@Atlassian.JIRA>
In-Reply-To: <JIRA.12904268.1444677015000@Atlassian.JIRA>
References: <JIRA.12904268.1444677015000@Atlassian.JIRA> <JIRA.12904268.1444677015923@arcas>
Subject: [jira] [Comment Edited] (REEF-832) Add CLOSING state to
 EvaluatorState
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 19 Jul 2016 06:12:22 -0000


    [ https://issues.apache.org/jira/browse/REEF-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383631#comment-15383631 ] 

Sanha Lee edited comment on REEF-832 at 7/19/16 6:12 AM:
---------------------------------------------------------

Hello [~MariiaMykhailova]. I took this issue yesterday.

In my understand, there are three conditions, which are ``DONE``, ``KILLED``, and ``FAILED``, in evaluator closing.
 - At present, for handling ``DONE`` and ``KILLED`` condition, ``EvaluatorManager`` sends evaluator control message and sets evaluator's state as ``DONE`` or ``KILLED``. After this, ``EvaluatorRuntime`` receives this message and shut down itself.
 - For handling ``FAILED`` condition, ``EvaluatorRuntime`` sends hearbeat with failed task status to ``EvaluatorManager`` when it experiences an exception, and close itself beforehand.
Therefore, I think that ``CLOSING`` state is not needed in ``FAILED`` condition, but only needed in ``DONE`` and ``KILLED`` conditions.

And, for adding ``CLOSING`` state to ``DONE`` and ``KILLED`` conditions, I'm considering design like below.
 - When ``EvalautorManager`` sends evaluator control message to shut down evaluator, it sets evaluator's state as ``CLOSING_DONE`` or ``CLOSING_KILLED`` instead of ``DONE`` or ``KILLED``.
 - When ``EvaluatorRuntime`` receives this message, it sends hearbeat with new task status like ``DOWNED` and shut down itself, instead of just shutting down itself.
 - When ``EvaluatorManager`` receives this message, it sets evaluator's state as ``DONE`` or ``KILLED``.

Please let me know whether my understanding and design is proper or not.


was (Author: sanha):
Hello [~MariiaMykhailova]. I took this issue yesterday.

In my understand, there are three conditions, which are `DONE`, `KILLED`, and `FAILED`, in evaluator closing.
 - At present, for handling `DONE` and `KILLED` condition, `EvaluatorManager` sends evaluator control message and sets evaluator's state as `DONE` or `KILLED`. After this, `EvaluatorRuntime` receives this message and shut down itself.
 - And for handling `FAILED` condition, `EvaluatorRuntime` sends hearbeat with failed task status to `EvaluatorManager` when it experiences an exception and close itself beforehand.
Therefore, I think that `CLOSING` state is not needed in `FAILED` condition, but only needed in `DONE` and `KILLED` conditions.

And, for adding `CLOSING` state to `DONE` and `KILLED` conditions, I'm considering design like below.
 - When `EvalautorManager` sends evaluator control message to shut down evaluator, it sets evaluator's state as `CLOSING_DONE` or `CLOSING_KILLED` instead of `DONE` or `KILLED`.
 - When `EvaluatorRuntime` receives this message, it sends hearbeat with new task status like 'DOWNED' and shut down itself, instead of just shutting down itself.
 - When `EvaluatorManager` receives this message, it sets evaluator's state as `DONE` or `KILLED`.

Please let me know whether my understanding and design is proper or not.

> Add CLOSING state to EvaluatorState
> -----------------------------------
>
>                 Key: REEF-832
>                 URL: https://issues.apache.org/jira/browse/REEF-832
>             Project: REEF
>          Issue Type: Improvement
>          Components: REEF-Common
>            Reporter: Mariia Mykhailova
>            Assignee: Sanha Lee
>            Priority: Minor
>
> {{org.apache.reef.runtime.common.driver.evaluator.EvaluatorState}} needs a CLOSING state to describe the time between asking an Evaluator to shut down and when that has actually happened. That would allow us to clean up the state checking code.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)