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)