Details
-
Improvement
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
Impala 2.8.0
-
None
-
Kerberos
-
ghx-label-9
Description
Similar to IMPALA-3875, on a kerberized system, when the HS2 server does the initial SASL negotiation after the open, if the client never sends any data, the read() will hang and hangs the entire server port.
In detail:
- TThreadPoolServer calls getTransport() on a client from the Server thread (the thread that does the accepts). - TSaslServerTransport->getTransport() calls TSaslTransport->open() - TSaslServerTransport->open() tries to negotiate SASL which calls read/write - If read/write blocks, the TThreadPoolServer cannot accept connections - This can be demonstrated by running against a kerberos enabled cluster: nc <impala host> <hs2 port> & then trying to connect to the hs2 port via beeline. The beeline connection will hang until the nc process is killed. - Can fix by setting the underlying TSocket recvTimeout and sendTimeout before the TSaslServerTransport->open() and reset them to 0 after open() completes. - Consider adding sasl_connect_tcp_timeout_seconds command line option (defaults to 10, 0 to disable)
Attachments
Issue Links
- duplicates
-
IMPALA-7566 TAcceptQueueServer connection setup should have timeout
- Resolved
- is duplicated by
-
IMPALA-5268 After canceling query on secure cluster coordinator node doesn't accept new connections
- Resolved
-
IMPALA-1941 TSaslServerTransport blocked by misbehaving clients
- Resolved
- is related to
-
IMPALA-7638 Lower default timeout for connection setup
- Open
-
IMPALA-5268 After canceling query on secure cluster coordinator node doesn't accept new connections
- Resolved
- Parent Feature
-
IMPALA-3380 Add TCP timeouts to all RPCs that don't block
- Resolved