You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Tim Armstrong (JIRA)" <ji...@apache.org> on 2018/10/26 01:25:00 UTC
[jira] [Resolved] (IMPALA-414) Impala server cannot detect
crash-restart failures reliably
[ https://issues.apache.org/jira/browse/IMPALA-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Armstrong resolved IMPALA-414.
----------------------------------
Resolution: Duplicate
I think this is describing IMPALA-2990 since we only need to detect crash-restart failures reliably in order to kill queries that were executing on the failed node.
> Impala server cannot detect crash-restart failures reliably
> -----------------------------------------------------------
>
> Key: IMPALA-414
> URL: https://issues.apache.org/jira/browse/IMPALA-414
> Project: IMPALA
> Issue Type: Improvement
> Components: Distributed Exec
> Affects Versions: Impala 1.0.1
> Reporter: Henry Robinson
> Priority: Minor
> Labels: statestore
>
> The membership mechanism used to tell Impala servers about failures does not always detect fast crash-restarts. If a server restarts and re-registers before the state-store recognises that it has failed, the failure won't get reported to any other subscriber.
> The right way to fix this, I think, is to track a version number in every subscriber. When a subscriber reconnects, it gets a new version number. For every query, we track the highest version number of the subscriber known at that time. Then if any backend executing a query has a higher version number, it's likely to have restarted since the query started. There might be a couple of false positives, since a node could conceivably restart between a scheduling assignment and actually receiving a query, but that's unlikely and better than false negatives.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)