[ https://issues.apache.org/jira/browse/SAMZA-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jagadish updated SAMZA-1769: ---------------------------- Description: The first step in computing the status of a StreamApplication is to run the ExecutionPlanner. Since the planner is run prior to everything else, any user-level misconfiguration that can cause the planner to fail will also cause AppRunner#status to fail. To make the computing of AppRunner#status more robust, we should not rely on the entire ExecutionPlan. Instead, a short-term alternative might be to directly query the cluster-manager by providing the app-name and app-id. The YARNJob class implements a lot of this logic - So, should offer us good leverage here. For the long-term, it would be preferrable to rely on the MetadataStore abstraction in Samza to store history about runs of an application. was: The first step in computing the status of a StreamApplication is to run the ExecutionPlanner. Hence, any misconfiguration by users that can cause the planner to fail will also cause AppRunner#status to fail. To make the computing of AppRunner#status more robust, we should not rely on the entire ExecutionPlan. Instead, a short-term alternative might be to directly query the cluster-manager by providing the app-name and app-id. The YARNJob class implements a lot of this logic - So, should offer us good leverage here. For the long-term, it would be preferrable to rely on the MetadataStore abstraction in Samza to store history about runs of an application. > AppRunner#Status should not throw exceptions > -------------------------------------------- > > Key: SAMZA-1769 > URL: https://issues.apache.org/jira/browse/SAMZA-1769 > Project: Samza > Issue Type: Bug > Reporter: Jagadish > Priority: Major > > The first step in computing the status of a StreamApplication is to run the > ExecutionPlanner. Since the planner is run prior to everything else, any > user-level misconfiguration that can cause the planner to fail will also > cause AppRunner#status to fail. > To make the computing of AppRunner#status more robust, we should not rely on > the entire ExecutionPlan. Instead, a short-term alternative might be to > directly query the cluster-manager by providing the app-name and app-id. The > YARNJob class implements a lot of this logic - So, should offer us good > leverage here. > For the long-term, it would be preferrable to rely on the MetadataStore > abstraction in Samza to store history about runs of an application. -- This message was sent by Atlassian JIRA (v7.6.3#76005)