You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Alexander Kolbasov (JIRA)" <ji...@apache.org> on 2018/05/03 07:03:00 UTC
[jira] [Commented] (HIVE-17166) Break Locks On Timeout
[ https://issues.apache.org/jira/browse/HIVE-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462023#comment-16462023 ]
Alexander Kolbasov commented on HIVE-17166:
-------------------------------------------
This looks rather strange. Essentially you propose to introduce a configuration that makes locking useless - the holder of the lock can no longer assume that invariants hold true since holding the lock doesn't mean anything.
> Break Locks On Timeout
> ----------------------
>
> Key: HIVE-17166
> URL: https://issues.apache.org/jira/browse/HIVE-17166
> Project: Hive
> Issue Type: New Feature
> Components: HiveServer2
> Affects Versions: 1.2.2, 2.1.1, 3.0.0
> Reporter: BELUGA BEHR
> Assignee: Janaki Lahorani
> Priority: Major
>
> Hive supports table and partition locks by utilizing ZooKeeper to keep track. There are several configurations related to this, including: {{hive.lock.sleep.between.retries}} and {{hive.lock.numretries}}.
> I'd lile to propose a new boolean configuration that, when set, would alter the behavior of a lock timeout failure. Instead of failing the query with an error, the configuration would direct Hive to break the lock and allow the query try to obtain a new one and proceed.
> This is useful in cases where locks are leaked and erroneously left behind. Such scenarios create permanent blocking on future queries. This break-lock mechanism would alleviate this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)