hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <>
Subject [jira] [Commented] (HIVE-14979) Removing stale Zookeeper locks at HiveServer2 initialization
Date Fri, 21 Oct 2016 01:01:26 GMT


Sergey Shelukhin commented on HIVE-14979:

ZK session timeout does seems excessive... not sure why it's like that. [~thejas] [~vgumashta]
can you comment?
In a default config, ZK probably won't even allow such a long timeout.

Reading ZK docs, it does seem like session timeout would allow the locks to ride over disconnection.
I wonder why e.g. LLAP registry updates so far despite this timeout value. 
I think we should reduce the timeout to ~3mins and commit this patch unless   [~thejas] [~vgumashta]
Also I wonder if we need to account for multi-HS2 scenarios at all.

> Removing stale Zookeeper locks at HiveServer2 initialization
> ------------------------------------------------------------
>                 Key: HIVE-14979
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>          Components: Locking
>            Reporter: Peter Vary
>            Assignee: Peter Vary
>         Attachments: HIVE-14979.3.patch, HIVE-14979.4.patch, HIVE-14979.patch
> HiveServer2 could use Zookeeper to store token that indicate that particular tables are
locked with the creation of persistent Zookeeper objects. 
> A problem can occur when a HiveServer2 instance creates a lock on a table and the HiveServer2
instances crashes ("Out of Memory" for example) and the locks are not released in Zookeeper.
This lock will then remain until it is manually cleared by an admin.
> There should be a way to remove stale locks at HiveServer2 initialization, helping the
admins life.

This message was sent by Atlassian JIRA

View raw message