reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julia (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (REEF-1466) Cancel the blocking message reading and close the task properly
Date Wed, 22 Jun 2016 00:25:57 GMT

     [ https://issues.apache.org/jira/browse/REEF-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julia updated REEF-1466:
------------------------
    Description: 
Currently when driver sends an event to kill a task, in IMRU task close handler, we set a
flag for the Call() method to return from next iteration. If the Call() method stuck in reading
messages, we throw IMRUTaskSystemException so that for the IMRU driver to receive IFailedTask.
After the drive killed all the tasks, the drive will resubmit tasks if the system is recoverable.


In REEF-1447, the proposed solution for exceptions throw from task close handler is to fail
the Evaluator. With the current IMRU task close handler, this would make all evaluators fail.
If we want to treat exceptions in close handler as FailedEvaluator, we must gracefully handle
the task close event instead of throw an exception. 

I would like to re-propose the cancellation token solution we discussed before. Pass a cancellation
token from task all the way to the NodeStruct.GetData(). When the task close handler is called,
cancel the cancellation token for the task to return properly. 

This will involve some GC/Network method signature changes, some are internal some are public.


Let me know if you have any concerns about this solution. 


  was:
Currently when driver sends event to kill a task, in IMRU task close handler, we set a flag
for the Call() method to return from next iteration. If the Call() method stuck in reading
messages, we throw IMRUTaskSystemException so that for the IMRU driver to receive IFailedTask.
After the drive killed all the tasks, the drive will resubmit tasks if it is recoverable.


In REEF-1447, the proposed solution for exceptions throw from task close handler is to fail
the Evaluator. With the current IMRU task close handler, this would make all evaluators fail.
If we want to treat exceptions in close handler as FailedEvaluator, we must gracefully handle
the task close event instead of throw an exception. 

I would like to re-propose the cancellation token solution we discussed before. Pass a cancellation
token from task all the way to the NodeStruct.GetData(). When the task close handler is called,
cancel the cancellation token for the task to return properly. 

This will involve some GC/Network method signature changes, some are internal some are public.


Let me know if you have any concerns about this solution. 



> Cancel the blocking message reading and close the task properly
> ---------------------------------------------------------------
>
>                 Key: REEF-1466
>                 URL: https://issues.apache.org/jira/browse/REEF-1466
>             Project: REEF
>          Issue Type: Task
>            Reporter: Julia
>
> Currently when driver sends an event to kill a task, in IMRU task close handler, we set
a flag for the Call() method to return from next iteration. If the Call() method stuck in
reading messages, we throw IMRUTaskSystemException so that for the IMRU driver to receive
IFailedTask. After the drive killed all the tasks, the drive will resubmit tasks if the system
is recoverable. 
> In REEF-1447, the proposed solution for exceptions throw from task close handler is to
fail the Evaluator. With the current IMRU task close handler, this would make all evaluators
fail. If we want to treat exceptions in close handler as FailedEvaluator, we must gracefully
handle the task close event instead of throw an exception. 
> I would like to re-propose the cancellation token solution we discussed before. Pass
a cancellation token from task all the way to the NodeStruct.GetData(). When the task close
handler is called, cancel the cancellation token for the task to return properly. 
> This will involve some GC/Network method signature changes, some are internal some are
public. 
> Let me know if you have any concerns about this solution. 



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

Mime
View raw message