hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Zhuge (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-11529) libHDFS still does not return appropriate error information in many cases
Date Mon, 17 Apr 2017 02:15:42 GMT

    [ https://issues.apache.org/jira/browse/HDFS-11529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15970596#comment-15970596
] 

John Zhuge commented on HDFS-11529:
-----------------------------------

Thank you [~sailesh] for working on the patch. Here is my review for patch 002.

exception.c
#149: Why rename? Doesn’t the function still print it? This touches off so many one-line
changes.
#178: Double space

exception.h
#23: Please update the javadoc:

expect.h
#168,169: Even though other places have done it, but I still find double-underscore prefix
wrong because variables with double-underscore prefix are supposed to be reserved.
#168-181: Replace “str” and “substr” in macro body with “(str)” and “(substr)”

posix/thread_local_storage.c
#32: Any reason to remove the javadoc?

Testing
I tried the patch on Centos 7.2. Unit tests passed.
Any testing done on Windows?

> libHDFS still does not return appropriate error information in many cases
> -------------------------------------------------------------------------
>
>                 Key: HDFS-11529
>                 URL: https://issues.apache.org/jira/browse/HDFS-11529
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: libhdfs
>    Affects Versions: 2.6.0
>            Reporter: Sailesh Mukil
>            Assignee: Sailesh Mukil
>            Priority: Critical
>              Labels: errorhandling, libhdfs
>         Attachments: HDFS-11529.000.patch, HDFS-11529.001.patch, HDFS-11529.002.patch
>
>
> libHDFS uses a table to compare exceptions against and returns a corresponding error
code to the application in case of an error.
> However, this table is manually populated and many times is disremembered when new exceptions
are added.
> This causes libHDFS to return EINTERNAL (or Unknown Error(255)) whenever these exceptions
are hit. These are some examples of exceptions that have been observed on an Error(255):
> org.apache.hadoop.ipc.StandbyException (Operation category WRITE is not supported in
state standby)
> java.io.EOFException: Cannot seek after EOF
> javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid
credentials provided (Mechanism level: Failed to find any Kerberos tgt)
> It is of course not possible to have an error code for each and every type of exception,
so one suggestion of how this can be addressed is by having a call such as hdfsGetLastException()
that would return the last exception that a libHDFS thread encountered. This way, an application
may choose to call hdfsGetLastException() if it receives EINTERNAL.
> We can make use of the Thread Local Storage to store this information. Also, this makes
sure that the current functionality is preserved.
> This is a follow up from HDFS-4997.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org


Mime
View raw message