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

Till Rohrmann commented on FLINK-6042:
--------------------------------------

Any signature change to {{AccessExecutionGraph}} needed to let 
{{ArchivedExecutionGraph}} return more {{ErrorInfos}} would also affect the 
{{ExecutionGraph}}. Hence, it might be easier to introduce a {{JobInformation}} 
object which is sent to the REST handlers. This object could contain the 
{{AccessExecutionGraph}} and additional information (e.g. the exception 
history).

Collecting and grouping the exceptions might be not super trivial. Keep in mind 
that not every recovery is a global recovery and there can potentially be 
concurrent recovery actions happening if we are running an embarrassingly 
parallel job. Conceptually, I guess that one should start collecting the 
exceptions whenever a failure occurs. This will then either trigger a recovery 
or failing the job. If it is a recovery, then one would collect all exceptions 
for the set of tasks to be restarted until one has restarted this set. If the 
failure leads to a job failure, then we cancel the job and collect all 
exceptions until the job has been canceled.

Since there can be concurrent recoveries happening, I am not sure whether the 
{{JobStatusListener}} is sufficient because you wouldn't notice the second 
recovery operation if you are already in the {{JobStatus.RESTARTING}}.

> Display last n exceptions/causes for job restarts in Web UI
> -----------------------------------------------------------
>
>                 Key: FLINK-6042
>                 URL: https://issues.apache.org/jira/browse/FLINK-6042
>             Project: Flink
>          Issue Type: Improvement
>          Components: Runtime / Coordination, Runtime / Web Frontend
>    Affects Versions: 1.3.0
>            Reporter: Till Rohrmann
>            Assignee: Matthias
>            Priority: Major
>
> Users requested that it would be nice to see the last {{n}} exceptions 
> causing a job restart in the Web UI. This will help to more easily debug and 
> operate a job.
> We could store the root causes for failures similar to how prior executions 
> are stored in the {{ExecutionVertex}} using the {{EvictingBoundedList}} and 
> then serve this information via the Web UI.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to