[
https://issues.apache.org/jira/browse/HIVE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593555#comment-15593555
]
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] object.
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: https://issues.apache.org/jira/browse/HIVE-14979
> 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
(v6.3.4#6332)
