[
https://issues.apache.org/jira/browse/HDDS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941456#comment-16941456
]
Arpit Agarwal commented on HDDS-2175:
-------------------------------------
bq. it is hard to parse these exceptions even when they are part of normal log
files.
And yet these exceptions are a godsend. I would rather see one exception than
10 obscure log messages since it tells me exactly when something 'exceptional'
happened and the code path leading to the occurrence.
bq. If we add exceptions to those strings, the human readability of those error
messages goes down.
The readability goes up. You now actually get a sense for what actually went
wrong instead of some generic message.
bq. I had a chat with Supratim Deka and I said that I am all for increasing the
fidelity of the error codes, that is we can add more error codes if we want to
fine tune these messages.
Lot more work with inferior results. Error codes are terrible in layered
systems [since multiple layers will often wind up translating
codes|https://twitter.com/Obdurodon/status/1161700056740876289]. The only way
to maintain full fidelity is add a new error code for every single failure
path, an impossible task. Instead just present the original exception as it
happened. This is friendlier for your end users and painless for developers.
bq. I prefer a clear, simple contract between the server and client, I think it
makes it easier for future clients to be developed more easily.
Exceptions as added here will make development of future clients super easy.
Since the exception is stringified and propagated over the wire, all the client
has to do is print the string without any interpretation. The fears seems
unfounded to me.
> Propagate System Exceptions from the OzoneManager
> -------------------------------------------------
>
> Key: HDDS-2175
> URL: https://issues.apache.org/jira/browse/HDDS-2175
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Components: Ozone Manager
> Reporter: Supratim Deka
> Assignee: Supratim Deka
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Exceptions encountered while processing requests on the OM are categorized as
> business exceptions and system exceptions. All of the business exceptions are
> captured as OMException and have an associated status code which is returned
> to the client. The handling of these is not going to be changed.
> Currently system exceptions are returned as INTERNAL ERROR to the client with
> a 1 line message string from the exception. The scope of this jira is to
> capture system exceptions and propagate the related information(including the
> complete stack trace) back to the client.
> There are 3 sub-tasks required to achieve this
> 1. Separate capture and handling for OMException and the other
> exceptions(IOException). For system exceptions, use Hadoop IPC
> ServiceException mechanism to send the stack trace to the client.
> 2. track and propagate exceptions inside Ratis OzoneManagerStateMachine and
> propagate up to the OzoneManager layer (on the leader). Currently, these
> exceptions are not being tracked.
> 3. Handle and propagate exceptions from Ratis.
> Will raise jira for each sub-task.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
