You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Bhushan Mandhani (JIRA)" <ji...@apache.org> on 2012/05/04 01:34:53 UTC

[jira] [Created] (HIVE-3001) Returning Meaningful Error Codes & Messages

Bhushan Mandhani created HIVE-3001:
--------------------------------------

             Summary: 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


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:

10000 to 19999: 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.
20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
40000 to 49999: 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] [Commented] (HIVE-3001) Returning Meaningful Error Codes & Messages

Posted by "Carl Steinbach (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274385#comment-13274385 ] 

Carl Steinbach commented on HIVE-3001:
--------------------------------------

I also noticed that Apache Derby has some SQLState code we may be able to reuse:

java/shared/org/apache/derby/shared/common/reference/SQLState.java
java/testing/org/apache/derbyTesting/functionTests/util/SQLStateConstants.java

                
> 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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

Posted by "Bhushan Mandhani (JIRA)" <ji...@apache.org>.
     [ 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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] [Commented] (HIVE-3001) Returning Meaningful Error Codes & Messages

Posted by "Carl Steinbach (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274387#comment-13274387 ] 

Carl Steinbach commented on HIVE-3001:
--------------------------------------

Hmm... I got so excited about ISO/ANSI error code standards I forgot to actually look at the patch. Looks like it improves support for returning SQLState codes. Cool!
                
> 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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

Posted by "Bhushan Mandhani (JIRA)" <ji...@apache.org>.
     [ 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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] [Commented] (HIVE-3001) Returning Meaningful Error Codes & Messages

Posted by "Carl Steinbach (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274384#comment-13274384 ] 

Carl Steinbach commented on HIVE-3001:
--------------------------------------

The error handling mechanisms employed by ODBC and JDBC both rely on SQLState error codes that have been standardized by ISO/ANSI and the Open Group (X/Open). It's obvious that we would have to extend the predefined SQLState codes in order to cover the full range of error conditions that are applicable to Hive, I still think it would make sense to use them as the foundation of Hive's error code system. Otherwise, anyone who implements an ODBC or JDBC driver for Hive is going to have to define their own mapping from Hive's internal error codes to SQLState codes, which is both time consuming and destined to result in inconsistent behavior across different driver implementations.

More information about SQLState error codes is available in the following page:
* http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp?topic=/com.ibm.sqls.doc/sqls548.htm
* http://msdn.microsoft.com/en-us/library/ms714687.aspx
* SQLState and JDBC SQLExceptions: http://docs.oracle.com/javase/tutorial/jdbc/basics/sqlexception.html

                
> 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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] [Commented] (HIVE-3001) Returning Meaningful Error Codes & Messages

Posted by "Namit Jain (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274296#comment-13274296 ] 

Namit Jain commented on HIVE-3001:
----------------------------------

Reviewing
                
> 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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] [Commented] (HIVE-3001) Returning Meaningful Error Codes & Messages

Posted by "Namit Jain (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HIVE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274469#comment-13274469 ] 

Namit Jain commented on HIVE-3001:
----------------------------------

The code changes look OK.

I ran all the tests and got the following failures:


Fix logs for TestContribNegativeCliDriver
240 TestNegativeCliDriver tests failed – did you update the logs correctly
TestCliDriver: failed tests
udft_explode2.q
auto_join25.q
TestNegativeMinimrCliDriver
TestSemanticAnalyzerHookLoading


Most of the above fixes may be log updates.
Please submit the new patch with the correct logs.

I will continue taking a look at the code changes, though they look OK to me.

                
> 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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

Posted by "Ashutosh Chauhan (JIRA)" <ji...@apache.org>.
     [ 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:
> 10000 to 19999: 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.
> 20000 to 29999: Runtime errors where Hive believes that retries will not succeed and the caller should not bother retrying.
> 30000 to 39999: Runtime errors which Hive thinks are probably transient and retrying may succeed.
> 40000 to 49999: 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