[
https://issues.apache.org/jira/browse/IMPALA-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-7420.
-----------------------------------
Resolution: Fixed
Fix Version/s: Impala 3.1.0
I added the infra to do this and converted some places. There are probably
other opportunities to leverage this but it was non-trivial to figure out where
the status would propagate to (we don't want to show an internal cancellation
error if the cancellation was ultimately client initiated). I think it makes
most sense to wait until the cancellation path is simplified, e.g. with
IMPALA-2990 and then revisit.
> Alternative cancellation messages with "internal" cancellation
> --------------------------------------------------------------
>
> Key: IMPALA-7420
> URL: https://issues.apache.org/jira/browse/IMPALA-7420
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Affects Versions: Impala 3.1.0
> Reporter: Tim Armstrong
> Assignee: Tim Armstrong
> Priority: Major
> Fix For: Impala 3.1.0
>
>
> All CANCELLED statuses now have the same error message regardless of the
> source of the cancellation. There are many places in the code where we
> propagate "CANCELLED" statuses around the place internally, e.g. within
> scans, for reasons unrelated to user-initiated cancellation. Those should not
> leak
> IMPALA-7418 was much harder to debug than necessary because it wasn't clear
> where the CANCELLED status came from.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
