You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@kudu.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2018/03/13 18:34:00 UTC

[jira] [Commented] (KUDU-2330) Exceptions thrown by Java client have inappropriate stack traces

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

Todd Lipcon commented on KUDU-2330:
-----------------------------------

Oops, just as I hit "commit" I realized I accidentally listed the wrong JIRA in the commit message of ce0db915787b58a79109e6faecc6f1daef9f2850

> Exceptions thrown by Java client have inappropriate stack traces
> ----------------------------------------------------------------
>
>                 Key: KUDU-2330
>                 URL: https://issues.apache.org/jira/browse/KUDU-2330
>             Project: Kudu
>          Issue Type: Bug
>          Components: client, java
>    Affects Versions: 1.7.0
>            Reporter: Todd Lipcon
>            Priority: Major
>
> Currently, the exceptions thrown by the Java client tend to have stack traces showing the point at which some error callback is called. The stack usually leads back to Netty reading a response from the wire, and not from the actual user code which invoked the call.
> For the async client this is somewhat unavoidable, and I think people have gotten used to stack traces in async clients being rather useless. But, in the synchronous wrapper, we should rewrite the stack traces so that the user's actual call stack is preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)