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

2018-03-13 Thread Todd Lipcon (JIRA)

 [ 
https://issues.apache.org/jira/browse/KUDU-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Todd Lipcon updated KUDU-2330:
--
Fix Version/s: (was: 1.8.0)

> 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
> Fix For: 1.7.0
>
>
> 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)


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

2018-03-13 Thread Grant Henke (JIRA)

 [ 
https://issues.apache.org/jira/browse/KUDU-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grant Henke updated KUDU-2330:
--
Fix Version/s: 1.7.0

> 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
> Fix For: 1.7.0, 1.8.0
>
>
> 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)


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

2018-03-13 Thread Todd Lipcon (JIRA)

 [ 
https://issues.apache.org/jira/browse/KUDU-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Todd Lipcon updated KUDU-2330:
--
   Resolution: Fixed
Fix Version/s: 1.8.0
   Status: Resolved  (was: In Review)

> 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
> Fix For: 1.8.0
>
>
> 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)