[
https://issues.apache.org/jira/browse/IMPALA-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868178#comment-17868178
]
Joe McDonnell commented on IMPALA-13183:
----------------------------------------
I was just about to file a Jira about having functionality to close idle
connections. This sounds similar, so I'm commenting here. We can split it off
if it is not quite the same.
Basically, there is no current mechanism to close idle connections that have no
session. There are circumstances where Hue and other clients that use a
connection pool can create these sessions. For example, Hue might want to close
a query that was executed by a different connection. It opens a connection
using the existing session, then when it tries to close the query/session, it
finds out that the query/session was already closed. This connection ends up
with no associated session and can stay that way for an indefinite period of
time.
We have seen cases where these connections can stay open on the server side
even after the client tries to close it. That seems to be happening with
certain load balancers, and it can cause the server to run out of fe service
threads.
> Add default timeout for hs2/beeswax server sockets
> --------------------------------------------------
>
> Key: IMPALA-13183
> URL: https://issues.apache.org/jira/browse/IMPALA-13183
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Reporter: Csaba Ringhofer
> Priority: Major
>
> Currently Impala only sets timeout for specific operations, for example
> during SASL handshake and when checking if connection can be closed due to
> idle session.
> https://github.com/apache/impala/blob/d39596f6fb7da54c24d02523c4691e6b1973857b/be/src/rpc/TAcceptQueueServer.cpp#L153
> https://github.com/apache/impala/blob/d39596f6fb7da54c24d02523c4691e6b1973857b/be/src/transport/TSaslServerTransport.cpp#L145
> There are several cases where an inactive client could keep the connection
> open indefinitely, for example if it hasn't opened a session yet.
> I think that there should be a general longer timeout set for both send/recv,
> e.g. flag client_default_timout_s=3600.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]