[
https://issues.apache.org/jira/browse/DRILL-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298260#comment-14298260
]
Hanifi Gunes commented on DRILL-1198:
-------------------------------------
If I am not mistaken, current client implementations rely on ZooKeeper solely
for cluster discovery purposes and not for failure detection. I am not
particularly sure about the C++ client though. Coming to your question, it
would be relatively easier to reason about re-executing the entire query. I
would be interested in knowing how the skip mechanism would work in general
though.
> 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: 0.9.0
>
>
> 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)
