[ 
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)

Reply via email to