[jira] [Resolved] (HIVE-26094) Compaction Worker thread not freeing the lock when lock status returned as WAITING

["Steve Carlin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HIVE-26094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Carlin resolved HIVE-26094.
---------------------------------
    Resolution: Duplicate

Duplicate of HIVE-25898

> Compaction Worker thread not freeing the lock when lock status returned as WAITING
> ----------------------------------------------------------------------------------
>
>                 Key: HIVE-26094
>                 URL: https://issues.apache.org/jira/browse/HIVE-26094
>             Project: Hive
>          Issue Type: New Feature
>          Components: Locking
>            Reporter: Steve Carlin
>            Priority: Major
>
> The following error occurs in the HS2 logs:
>  
> {code:java}
> (Worker.java:findNextCompactionAndExecute(538)) - Caught an exception in the main loop of compactor worker hiveserver2-0.hiveserver2-service.compute-1648522810-vk7c.svc.cluster.local-62
> org.apache.thrift.TException: Unable to acquire lock(s) on {boa_small_feng.stocks_boa_2019.year=2013}, status {WAITING}, reason {null}
> {code}
> This happens when the compactor thread tries to grab a lock on a table that already has a lock on it.  
> On the HMS side, the lock is saved in the database and queues up the lock.  This queued up lock will block other tables from grabbing the lock even after the original lock is removed.
> When the Worker object on the client side sees this status, it should either unlock immediately if it chooses not to run compaction or keep rechecking the lock.  Currently it does neither. 
> The effect of this is that the lock stays on the table until it times out. This prevents other threads from grabbing the lock.
> The code should probably change to remove the lock immediately.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)