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)