[jira] [Updated] (HIVE-3001) Returning Meaningful Error Codes Messages
[ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosh Chauhan updated HIVE-3001: --- Affects Version/s: 0.9.0 Fix Version/s: (was: 0.9.0) 0.10.0 Returning Meaningful Error Codes Messages --- Key: HIVE-3001 URL: https://issues.apache.org/jira/browse/HIVE-3001 Project: Hive Issue Type: New Feature Components: Diagnosability Affects Versions: 0.8.1, 0.9.0 Reporter: Bhushan Mandhani Assignee: Bhushan Mandhani Priority: Minor Labels: diagnostics Fix For: 0.10.0 Attachments: HIVE-3001.1.patch.txt Original Estimate: 48h Remaining Estimate: 48h Hive does not return meaningful error messages for runtime errors. Also, the same error code is returned for a whole bunch of unrelated errors. A programmatic caller cannot decide if it should retry or give up. This JIRA will get the ball rolling for having Hive return useful error codes and display useful messages when something goes wrong. I propose the following partitioning of error codes: 1 to 1: Errors that occur during semantic analysis and compilation of the query. Hive already does a pretty good job for these. Error codes will be attached to the error messages currently being used. 2 to 2: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying. 3 to 3: Runtime errors which Hive thinks are probably transient and retrying may succeed. 4 to 4: Runtime errors where Hive is unable to say anything about whether retries will succeed or not. Ideally, we want to avoid using this range as much as possible. Once we have this in place, over time we can migrate errors occurring in Hive operators to use this scheme. This patch will deal with setting up the error code space, setting up the mechanism for failed MapReduce tasks to relay the error code back to Hive client, and using this new scheme for a couple of common errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HIVE-3001) Returning Meaningful Error Codes Messages
[ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhushan Mandhani updated HIVE-3001: --- Attachment: HIVE-3001.1.patch.txt Reviewed in https://reviews.facebook.net/D3153 Returning Meaningful Error Codes Messages --- Key: HIVE-3001 URL: https://issues.apache.org/jira/browse/HIVE-3001 Project: Hive Issue Type: New Feature Components: Diagnosability Affects Versions: 0.9.1 Reporter: Bhushan Mandhani Assignee: Bhushan Mandhani Priority: Minor Fix For: 0.9.1 Attachments: HIVE-3001.1.patch.txt Original Estimate: 48h Remaining Estimate: 48h Hive does not return meaningful error messages for runtime errors. Also, the same error code is returned for a whole bunch of unrelated errors. A programmatic caller cannot decide if it should retry or give up. This JIRA will get the ball rolling for having Hive return useful error codes and display useful messages when something goes wrong. I propose the following partitioning of error codes: 1 to 1: Errors that occur during semantic analysis and compilation of the query. Hive already does a pretty good job for these. Error codes will be attached to the error messages currently being used. 2 to 2: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying. 3 to 3: Runtime errors which Hive thinks are probably transient and retrying may succeed. 4 to 4: Runtime errors where Hive is unable to say anything about whether retries will succeed or not. Ideally, we want to avoid using this range as much as possible. Once we have this in place, over time we can migrate errors occurring in Hive operators to use this scheme. This patch will deal with setting up the error code space, setting up the mechanism for failed MapReduce tasks to relay the error code back to Hive client, and using this new scheme for a couple of common errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HIVE-3001) Returning Meaningful Error Codes Messages
[ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhushan Mandhani updated HIVE-3001: --- Fix Version/s: (was: 0.9.1) 0.9.0 Labels: diagnostics (was: ) Affects Version/s: (was: 0.9.1) 0.8.1 Status: Patch Available (was: Open) Returning Meaningful Error Codes Messages --- Key: HIVE-3001 URL: https://issues.apache.org/jira/browse/HIVE-3001 Project: Hive Issue Type: New Feature Components: Diagnosability Affects Versions: 0.8.1 Reporter: Bhushan Mandhani Assignee: Bhushan Mandhani Priority: Minor Labels: diagnostics Fix For: 0.9.0 Attachments: HIVE-3001.1.patch.txt Original Estimate: 48h Remaining Estimate: 48h Hive does not return meaningful error messages for runtime errors. Also, the same error code is returned for a whole bunch of unrelated errors. A programmatic caller cannot decide if it should retry or give up. This JIRA will get the ball rolling for having Hive return useful error codes and display useful messages when something goes wrong. I propose the following partitioning of error codes: 1 to 1: Errors that occur during semantic analysis and compilation of the query. Hive already does a pretty good job for these. Error codes will be attached to the error messages currently being used. 2 to 2: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying. 3 to 3: Runtime errors which Hive thinks are probably transient and retrying may succeed. 4 to 4: Runtime errors where Hive is unable to say anything about whether retries will succeed or not. Ideally, we want to avoid using this range as much as possible. Once we have this in place, over time we can migrate errors occurring in Hive operators to use this scheme. This patch will deal with setting up the error code space, setting up the mechanism for failed MapReduce tasks to relay the error code back to Hive client, and using this new scheme for a couple of common errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
