[
https://issues.apache.org/jira/browse/TEZ-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149204#comment-15149204
]
Hitesh Shah commented on TEZ-3029:
----------------------------------
General functional comments about the patch:
- processNonFatalServiceErrorReport does not do anything for the case where
an error is reported for a dag that does not match the current one. Silently
ignored? Also, should this API ever be allowed to be invoked with a null
daginfo object? For now, both the dagInfo null and the non-matching dags can be
logged as a warn.
- DAG_TERMINATED in DAGTerminationCause seems ambiguous as it implies
killed by someone. This could be retained for killed by the user/client/yarn.
For service plugins, why not just add a termination cause denoting service
plugin error ( either one or 3 different errors ) to make it more clear. A
similar change might be needed for VertexTerminationCause. A service plugin
error should still fail the dag. It is not a kill as a kill indicates no
problems happened and the dag was just interrupted for some reason whatsoever.
- diagnostics in DAGAppMasterEventSchedulingServiceError - is this expected
to be a string + exception stack trace?
- dont like the idea of the incomplete ctor var - does this really need to be
there? Also, can "public ContainerLauncherManager(AppContext context)" be just
made package private for testing?
- // KKK Remove deprecated methods - maybe replace the KKK with a TODO to
avoid any acronym confusion?
> Add an onError method to service plugin contexts
> ------------------------------------------------
>
> Key: TEZ-3029
> URL: https://issues.apache.org/jira/browse/TEZ-3029
> Project: Apache Tez
> Issue Type: Sub-task
> Reporter: Siddharth Seth
> Assignee: Siddharth Seth
> Attachments: TEZ-3029.1.txt, TEZ-3029.2.txt, TEZ-3029.3.txt
>
>
> This is to indicate errors which may occur while running threads etc.
> One bit to be careful about is that this introduces two means of reporting
> errors - which has been challenging to handle in the past for
> Input/Processor/OutputContext - so whether to do this or not needs to be
> thought through.
> TaskSchedulerContext already has this method.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
