Mailing-List: contact dev-help@reef.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@reef.apache.org
Date: Tue, 30 Aug 2016 17:59:20 +0000 (UTC)
From: "Dhruv Mahajan (JIRA)" <jira@apache.org>
To: dev@reef.apache.org
Message-ID: <JIRA.12972262.1464056015000.449336.1472579960695@Atlassian.JIRA>
In-Reply-To: <JIRA.12972262.1464056015000@Atlassian.JIRA>
References: <JIRA.12972262.1464056015000@Atlassian.JIRA> <JIRA.12972262.1464056015047@arcas>
Subject: [jira] [Commented] (REEF-1404) IMRU task state Maintenance and
 Preservation in Evaluator for fault tolerant
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 30 Aug 2016 17:59:22 -0000


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

Dhruv Mahajan commented on REEF-1404:
-------------------------------------

I see ... so in that case, what prevents us from simply have an empty {{IStateManager}} interface and then each IMRU application simply bind appropriate implementation to it? Let the user have full control over fading away, persisting to disk or remote location, etc. In other words, what are the functionalities in IStateManager that we would like IMRU framework to maintain implicitly without user knowing about it?

> IMRU task state Maintenance and Preservation in Evaluator for fault tolerant
> ----------------------------------------------------------------------------
>
>                 Key: REEF-1404
>                 URL: https://issues.apache.org/jira/browse/REEF-1404
>             Project: REEF
>          Issue Type: Task
>            Reporter: Julia
>              Labels: FT
>
> IMRU task should be able to 
> * Maintenance and preservation the state
> * When restart, able to recover from the previous sate


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