You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Parth Chandra (JIRA)" <ji...@apache.org> on 2015/03/20 22:57:38 UTC
[jira] [Updated] (DRILL-1198) C++ DrillClient need to negotiate
with Zookeeper quorum if/when an assigned DrillBit fails
[ https://issues.apache.org/jira/browse/DRILL-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Parth Chandra updated DRILL-1198:
---------------------------------
Fix Version/s: (was: 0.9.0)
Future
> C++ DrillClient need to negotiate with Zookeeper quorum if/when an assigned DrillBit fails
> ------------------------------------------------------------------------------------------
>
> Key: DRILL-1198
> URL: https://issues.apache.org/jira/browse/DRILL-1198
> Project: Apache Drill
> Issue Type: Improvement
> Components: Client - C++
> Reporter: George Chow
> Assignee: Parth Chandra
> Priority: Minor
> Fix For: Future
>
>
> Current DrillClient does not recover from a DrillBit failure when the connection is initiated via a Zookeeper quorum.
> This JIRA covers adding this capability to the C++ DrillClient.
> The key question to consider: how far does the DrillClient go in recovering the connection? One interesting example to consider if when the DrillBit fails in the middle of a query.
> Scenario:
> 1. An app connects via ODBC to a Drill cluster via the ZK quorum. ZK assigns a Drillbit node1 to the connection.
> 2. The app issues a query and node1 starts processing the query and returns 2 RecordBatches back
> 3. node1 fails.
> 4. DrillClient detects the loss of node1 and negotiates with the quorum for a replacement, node2
> 5. Question: does DrillClient try to re-execute the query and skip over the first two RecordBatches (since DrillClient knows that was the state of the connection to node1)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)