You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Tim Armstrong (JIRA)" <ji...@apache.org> on 2018/09/19 22:26:00 UTC
[jira] [Resolved] (IMPALA-7420) Alternative cancellation messages
with "internal" cancellation
[ 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org