Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 21 Apr 2017 00:42:04 +0000 (UTC)
From: "John Zhuge (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.13055878.1489482305000.13361.1492735324279@Atlassian.JIRA>
In-Reply-To: <JIRA.13055878.1489482305000@Atlassian.JIRA>
References: <JIRA.13055878.1489482305000@Atlassian.JIRA> <JIRA.13055878.1489482305832@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HDFS-11529) Add libHDFS API to return last
 exception
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 21 Apr 2017 00:42:09 -0000


    [ https://issues.apache.org/jira/browse/HDFS-11529?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1597=
7870#comment-15977870 ]=20

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

Patch 005 looks really good.

exception.h
* 32: Remove =E2=80=9C()=E2=80=9D
* 36-38: Mention =E2=80=9ChdfsGetLastExceptionRootCause=E2=80=9D and =E2=80=
=9ChdfsGetLastExceptionStackTrace=E2=80=9D

Can anyone from the community help with build and testing on Windows?


> Add libHDFS API to return last exception
> ----------------------------------------
>
>                 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-115=
29.002.patch, HDFS-11529.003.patch, HDFS-11529.004.patch, HDFS-11529.005.pa=
tch
>
>
> libHDFS uses a table to compare exceptions against and returns a correspo=
nding 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 b=
een observed on an Error(255):
> org.apache.hadoop.ipc.StandbyException (Operation category WRITE is not s=
upported in state standby)
> java.io.EOFException: Cannot seek after EOF
> javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSExce=
ption: No valid credentials provided (Mechanism level: Failed to find any K=
erberos tgt)
> It is of course not possible to have an error code for each and every typ=
e 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. Al=
so, 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