[
https://issues.apache.org/jira/browse/HDFS-11529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974136#comment-15974136
]
John Zhuge commented on HDFS-11529:
-----------------------------------
{quote}
> This was a comment left by Colin. The reason for the name change is that it
> now does more than just print the exception. It also handles it by updating
> the TLS, so leaving the name as printExceptionAndFree() would have been a
> little misleading.
Guess we are in pretty subjective territory. Just hate to see many one-liners,
maybe keeping {{printExceptionAndFree}} as a wrapper of
{{handleExceptionAndFree}}? My 2 cents. [~cmccabe] Could you comment?
{quote}
After pondering it more, the wrapper is not a good idea. I am leaning a little
bit towards staying with {{printExceptionAndFree}} but don't object to
{{handleExceptionAndFree}}.
> 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-11529.002.patch, HDFS-11529.003.patch, HDFS-11529.004.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: [email protected]
For additional commands, e-mail: [email protected]
