hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chaoyu Tang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-9423) HiveServer2: Implement some admission control mechanism for graceful degradation when resources are exhausted
Date Thu, 22 Sep 2016 13:45:20 GMT

    [ https://issues.apache.org/jira/browse/HIVE-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513336#comment-15513336
] 

Chaoyu Tang commented on HIVE-9423:
-----------------------------------

[~pvary] I have a small question about the message and suggestion presented to Beeline user
when they run into login timeout issue such as
{code}
+hs2-unexpected-end-of-file: Unexpected end of file when reading from HS2 server. The root
\
+cause might be too many concurrent connections. Please check the number of active \
+connections, and adjust hive.server2.thrift.max.worker.threads if applicable.
{code}
Do you think that these Beeline user has the privilege to "check the number of active connections,
and adjust hive.server2.thrift.max.worker.threads if applicable"

> HiveServer2: Implement some admission control mechanism for graceful degradation when
resources are exhausted
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-9423
>                 URL: https://issues.apache.org/jira/browse/HIVE-9423
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2
>    Affects Versions: 0.12.0, 0.13.0, 0.14.0, 0.15.0
>            Reporter: Vaibhav Gumashta
>            Assignee: Peter Vary
>         Attachments: HIVE-9423.2.patch, HIVE-9423.3.patch, HIVE-9423.patch
>
>
> An example of where it is needed: it has been reported that when # of client connections
is greater than   {{hive.server2.thrift.max.worker.threads}}, HiveServer2 stops accepting
new connections and ends up having to be restarted. This should be handled more gracefully
by the server and the JDBC driver, so that the end user gets aware of the problem and can
take appropriate steps (either close existing connections or bump of the config value or use
multiple server instances with dynamic service discovery enabled). Similarly, we should also
review the behaviour of background thread pool to have a well defined behavior on the the
pool getting exhausted. 
> Ideally implementing some form of general admission control will be a better solution,
so that we do not accept new work unless sufficient resources are available and display graceful
degradation under overload.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message