[
https://issues.apache.org/jira/browse/TEZ-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998414#comment-13998414
]
Bikas Saha commented on TEZ-1117:
---------------------------------
We need to understand what it means per the semantics of the operation. The
interface to get information about the DAG is the DAGClient. Not the app. That
is by design. Eventually when we have the UI, we will be able to show the DAGs
that ran in the session. That, IMO is more clear way to show success/failure.
e.g. if dag 1,2, 3 ran in session and dag 2 failed should the app/session fail?
How does the session know that its not really running in session mode?
Lets try to understand the scenario further. I would argue that a Pig script
(non console) should not use the session API. The session API is not fire and
forget. The DAG cannot be submitted to the session until the app starts running
and accepts the DAG over RPC. Which means that its stuck on a busy cluster. If
we do this then users cannot fire their Pig scripts and go away. They need to
maintain the running console until resources free up in the cluster at some
unbounded time in the future. At some point the client side code will give up
on the app and bail out. I wonder why we haven't hit this issue (which would be
even more problematic). Session is meant for the console use case where there
is a real user on the console who is going to interact with the analytics. Its
not meant for scheduled job submission. Multi-dag Pig scripts should be fine to
submit in 1 app since a disjoint graph is supported.
> Option to make YARN application failed on dag failure
> -----------------------------------------------------
>
> Key: TEZ-1117
> URL: https://issues.apache.org/jira/browse/TEZ-1117
> Project: Apache Tez
> Issue Type: Improvement
> Reporter: Rohini Palaniswamy
>
> Can we have an configuration to make the Application status FAILED on
> termination if one of the DAGs fail? It is very confusing for users to see
> the application SUCCEEDED.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
