impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sherman (Code Review)" <ger...@cloudera.org>
Subject [Impala-ASF-CR] IMPALA-5394: Set socket timeouts while opening TSaslTransport
Date Mon, 05 Jun 2017 18:30:08 GMT
John Sherman has posted comments on this change.

Change subject: IMPALA-5394: Set socket timeouts while opening TSaslTransport
......................................................................


Patch Set 1:

> (1 comment)
 > 
 > Thanks John. The internal connection timeout is actually 5 minutes:
 > https://github.com/apache/incubator-impala/blob/master/be/src/runtime/exec-env.cc#L118-L123
 > 
 > We would also want the client connection timeout to default to a
 > pretty high number since on large clusters, we've seen Kerberos
 > negotiations take up to a few minutes.
 > I would prefer keeping the timeout to 5 minutes. It's not ideal,
 > however, we would rather not see queries fail because of timed out
 > negotiations vs. optimize for an even worse case of clients hung
 > for 5 minutes (which is configurable by a flag if the user chooses
 > to do so). This is the same reason we keep the internal connection
 > timeout so high, since we'd rather see progress than a failed query
 > due to one timed out connection.

I will make those changes. I was basing my (incorrect) comment off of the statestore_heartbeat_tcp_timeout_seconds
flag (which I modeled the flag off of). I also see that statestore_update_tcp_timeout_seconds
is 300 seconds. Thanks for pointing out backend_client_rpc_timeout_ms.

 > (1 comment)
 > 
 > Thanks John. The internal connection timeout is actually 5 minutes:
 > https://github.com/apache/incubator-impala/blob/master/be/src/runtime/exec-env.cc#L118-L123
 > 
 > We would also want the client connection timeout to default to a
 > pretty high number since on large clusters, we've seen Kerberos
 > negotiations take up to a few minutes.
 > I would prefer keeping the timeout to 5 minutes. It's not ideal,
 > however, we would rather not see queries fail because of timed out
 > negotiations vs. optimize for an even worse case of clients hung
 > for 5 minutes (which is configurable by a flag if the user chooses
 > to do so). This is the same reason we keep the internal connection
 > timeout so high, since we'd rather see progress than a failed query
 > due to one timed out connection.

-- 
To view, visit http://gerrit.cloudera.org:8080/7061
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I56a5f3d9cf931cff14eae7f236fea018236a6255
Gerrit-PatchSet: 1
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: John Sherman <jfs@arcadiadata.com>
Gerrit-Reviewer: John Sherman <jfs@arcadiadata.com>
Gerrit-Reviewer: Sailesh Mukil <sailesh@cloudera.com>
Gerrit-HasComments: No

Mime
View raw message