You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Thomas Tauber-Marshall (Jira)" <ji...@apache.org> on 2020/01/09 23:34:00 UTC
[jira] [Commented] (IMPALA-6159) DataStreamSender should
transparently handle some connection reset by peer
[ https://issues.apache.org/jira/browse/IMPALA-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012297#comment-17012297 ]
Thomas Tauber-Marshall commented on IMPALA-6159:
------------------------------------------------
I took a look, and I'm pretty confident that the particular issue discussed in this JIRA, "connection reset' errors resulting from closed sockets, is no longer a problem. There are various other improvements in this general area we could consider, such as the things discussed in the linked JIRAs, but I think its fine to close this JIRA and file new ones for anything else we want to do.
> DataStreamSender should transparently handle some connection reset by peer
> --------------------------------------------------------------------------
>
> Key: IMPALA-6159
> URL: https://issues.apache.org/jira/browse/IMPALA-6159
> Project: IMPALA
> Issue Type: Sub-task
> Components: Distributed Exec
> Affects Versions: Impala 2.12.0
> Reporter: Michael Ho
> Assignee: Michael Ho
> Priority: Critical
>
> A client to server KRPC connection can become stale if the socket was closed on the server side due to various reasons such as idle connection removal or remote Impalad restart. Currently, the KRPC code will invoke the callback of all RPCs using that stale connection with the failed status (e.g. "Connection reset by peer"). DataStreamSender should pattern match against certain error string (as they are mostly output from strerror()) and retry the RPC transparently. This may be also be useful for KUDU-2192 which tracks the effort to detect stuck connection and close them. In which case, we may also want to transparently retry the RPC
> FWIW, KUDU-279 is tracking the effort to have a cleaner protocol for connection teardown due to idle client connection removal on the server side. However, Impala still needs to handle other reasons for a stale connection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org