[
https://issues.apache.org/jira/browse/IMPALA-9253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107794#comment-17107794
]
Thomas Tauber-Marshall commented on IMPALA-9253:
------------------------------------------------
Yeah, I dug into the particular case more, and it seems that what happened is
that the impalad started successfully and authenticated to kerberos, then at
some point later the credential cache file got corrupted and further attempts
to renew the kerberos ticket failed.
We actually fixed that particular problem in IMPALA-9359, but who knows what
types of errors might crop up in the future, so we should think about how to
design this to work well even with errors we haven't anticipated yet.
> Blacklist additional posix error codes for failed DataStreamService RPCs
> ------------------------------------------------------------------------
>
> Key: IMPALA-9253
> URL: https://issues.apache.org/jira/browse/IMPALA-9253
> Project: IMPALA
> Issue Type: Sub-task
> Reporter: Sahil Takiar
> Priority: Major
>
> Filing as a follow up to
> [IMPALA-9137|http://issues.cloudera.org/browse/IMPALA-9137],
> [IMPALA-9137|http://issues.cloudera.org/browse/IMPALA-9137] blacklists a node
> if a RPC fails with specific posix error codes:
> * 107 = ENOTCONN: Transport endpoint is not connected
> * 108 = ESHUTDOWN: Cannot send after transport endpoint shutdown
> * 111 = ECONNREFUSED: Connection refused
> These codes were produced by running a query, killing a node running that
> query, and then seeing what error codes the query failed with.
> There may be other error codes that are worth using for node blacklisting as
> well. One way to come up with more error codes is to use iptables to
> introduce network faults between Impala processes and see how RPCs fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
