[ 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-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org