Mailing-List: contact issues-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Thu, 22 Sep 2016 15:19:20 +0000 (UTC)
From: "Peter Vary (JIRA)" <jira@apache.org>
To: issues@hive.apache.org
Message-ID: <JIRA.12768793.1421788300000.638968.1474557560484@Atlassian.JIRA>
In-Reply-To: <JIRA.12768793.1421788300000@Atlassian.JIRA>
References: <JIRA.12768793.1421788300000@Atlassian.JIRA> <JIRA.12768793.1421788300658@arcas>
Subject: [jira] [Updated] (HIVE-9423) HiveServer2: Implement some admission
 control mechanism for graceful degradation when resources are exhausted
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 22 Sep 2016 15:19:22 -0000


     [ https://issues.apache.org/jira/browse/HIVE-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Vary updated HIVE-9423:
-----------------------------
    Attachment: HIVE-9423.4.patch

Changed the messages according to [~ctang.ma] suggestion.

Thanks,
Peter

> 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.4.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)