[
https://issues.apache.org/jira/browse/HDFS-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16191693#comment-16191693
]
Anu Engineer commented on HDFS-12583:
-------------------------------------
[~vagarychen], [~cheersyang], [~linyiqun] Thanks for a very interesting
discussion.
I am of the opinion that even if we carry the full exception to the client, it
still has to be encapsulated inside the error model that we support. Here is
the issue with exceptions, they don't work well across process boundaries. It
assumes that the clients are always in Java or the fact that clients can
understand what these exceptions mean. If we start leaking these server-side
abstractions over RPC, then writing clients in any language other than java
becomes harder. So in the Ozone world, it is imperative that we keep the
current model, so we can write ozone clients in other languages like C++ or
python without hard-coded java language features.
Given that, if you want to send an additional string which other languages can
ignore and Java clients have a special meaning, I am ok with that (but I would
like to avoid) since in my mind RPC protocol is a boundary where the Server
abstractions don't leak over but are always clearly defined via protobuf. In a
perfect world, (I am not asking us to do this) the way to send a Java exception
on the wire, would be to create a protobuf struct called java exception and
send that stack over and those various clients can decode. However, in a
practical sense, no client (not even Java) clients decode the stack, instead,
they just print it to log/screen. So it be might something you can add as an
inner exception and send across as a string if it helps.
> Ozone: Fix swallow exceptions which makes hard to debug failures
> ----------------------------------------------------------------
>
> Key: HDFS-12583
> URL: https://issues.apache.org/jira/browse/HDFS-12583
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Affects Versions: HDFS-7240
> Reporter: Yiqun Lin
> Assignee: Yiqun Lin
> Attachments: HDFS-12583-HDFS-7240.001.patch,
> HDFS-12583-HDFS-7240.002.patch, HDFS-12583-HDFS-7240.003.patch
>
>
> There are some places that swallow exceptions that makes client hard to debug
> the failure. For example, if we get xceiver client from xceiver client
> manager error, client only gets the error info like this:
> {noformat}
> org.apache.hadoop.ozone.web.exceptions.OzoneException: Exception getting
> XceiverClient.
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> com.fasterxml.jackson.databind.introspect.AnnotatedConstructor.call(AnnotatedConstructor.java:119)
> at
> com.fasterxml.jackson.databind.deser.std.StdValueInstantiator.createUsingDefault(StdValueInstantiator.java:243)
> {noformat}
> The error exception stack is missing. We should print the error log as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
