hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Vary (JIRA)" <>
Subject [jira] [Commented] (HIVE-9423) HiveServer2: Provide the user with different error messages depending on the Thrift client exception code
Date Tue, 27 Sep 2016 16:17:20 GMT


Peter Vary commented on HIVE-9423:

Hi [~vgumashta],

Ok - I kept the description to document that there is no hangs any more. I would be happy
to help in that jira - maybe I was wrong when I thought that having hive.server2.thrift.max.worker.threads,
hive.server2.thrift.min.worker.threads, hive.server2.thrift.exponential.backoff.slot.length
and hive.server2.thrift.login.timeout to control the Thrift server connection   settings is

Since 0.9.2 the Thrift code respect the configurations above - no hangs, and restarts are
needed -, and with this patch I try to provide a meaningful error message.

If you have something even better, I would be happy to help.

Thanks to checking out this jira,

> HiveServer2: Provide the user with different error messages depending on the Thrift client
exception code
> ---------------------------------------------------------------------------------------------------------
>                 Key: HIVE-9423
>                 URL:
>             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.4.patch, HIVE-9423.5.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

View raw message