[
https://issues.apache.org/jira/browse/HIVE-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464962#comment-16464962
]
BELUGA BEHR commented on HIVE-17166:
------------------------------------
[~akolb] Yes, not a standard feature, but there have been issues in the past
where a lock is leaked and gums up everything. If you know that your
environment does not have a 6hr query, but a query is stuck on a lock for that
long, the assumption is that something went wrong and the jam needs to be
cleared instead of failing the workload.
> 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)
