Return-Path: X-Original-To: apmail-hive-dev-archive@www.apache.org Delivered-To: apmail-hive-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1ECC911A52 for ; Mon, 25 Aug 2014 18:48:59 +0000 (UTC) Received: (qmail 48697 invoked by uid 500); 25 Aug 2014 18:48:58 -0000 Delivered-To: apmail-hive-dev-archive@hive.apache.org Received: (qmail 48626 invoked by uid 500); 25 Aug 2014 18:48:58 -0000 Mailing-List: contact dev-help@hive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hive.apache.org Delivered-To: mailing list dev@hive.apache.org Received: (qmail 48612 invoked by uid 500); 25 Aug 2014 18:48:58 -0000 Delivered-To: apmail-hadoop-hive-dev@hadoop.apache.org Received: (qmail 48609 invoked by uid 99); 25 Aug 2014 18:48:58 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2014 18:48:58 +0000 Date: Mon, 25 Aug 2014 18:48:58 +0000 (UTC) From: "Brock Noland (JIRA)" To: hive-dev@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HIVE-5799) session/operation timeout for hiveserver2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HIVE-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109489#comment-14109489 ] Brock Noland commented on HIVE-5799: ------------------------------------ # It appears the constant SessionManager. SESSION_CHECK_INTERVAL is unused. # HiveSessionImpl. opHandleSet should be converted to a synchronized set or a concurrent set since it's now modified by the client thread and the background thread # I think we should call OperationManager._getOperation getOperationInternal as that seems to be more standard for this use case in the Hive code base. # Perhaps we should change OperationManager.closeExpiredOperations to not use closeOperation but use similar code since it appears there is a harmless race condition there which will log exceptions when the operation is closed during closeExpiredOperations Does anyone else have any feedback? Otherwise once these are fixed I think we can commit. > session/operation timeout for hiveserver2 > ----------------------------------------- > > Key: HIVE-5799 > URL: https://issues.apache.org/jira/browse/HIVE-5799 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 > Reporter: Navis > Assignee: Navis > Priority: Minor > Attachments: HIVE-5799.1.patch.txt, HIVE-5799.10.patch.txt, HIVE-5799.11.patch.txt, HIVE-5799.12.patch.txt, HIVE-5799.12.patch.txt, HIVE-5799.2.patch.txt, HIVE-5799.3.patch.txt, HIVE-5799.4.patch.txt, HIVE-5799.5.patch.txt, HIVE-5799.6.patch.txt, HIVE-5799.7.patch.txt, HIVE-5799.8.patch.txt, HIVE-5799.9.patch.txt > > > Need some timeout facility for preventing resource leakages from instable or bad clients. -- This message was sent by Atlassian JIRA (v6.2#6252)