hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Szehon Ho (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HIVE-7445) Improve LOGS for Hive when a query is not able to acquire locks
Date Fri, 18 Jul 2014 19:24:04 GMT

    [ https://issues.apache.org/jira/browse/HIVE-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066764#comment-14066764
] 

Szehon Ho commented on HIVE-7445:
---------------------------------

Hi Chaoyu this is a great idea.  

Thought I'm a little concerned that 'conflictingLocks' is a member variable of the shared
ZKLockManager instance.  Would that be an issue with different threads calling lock() at same
time, as they are sharing access on the variable?  Can it be done differently, for example
if lock() method passed in a flag to lockPrimitive() telling it whether to print the log?
 Then it can just make the 'conflictingLock' list locally in the method and print it.  Also
appreciate a RB for easier viewing :)

> Improve LOGS for Hive when a query is not able to acquire locks
> ---------------------------------------------------------------
>
>                 Key: HIVE-7445
>                 URL: https://issues.apache.org/jira/browse/HIVE-7445
>             Project: Hive
>          Issue Type: Improvement
>          Components: Diagnosability, Logging
>    Affects Versions: 0.13.1
>            Reporter: Chaoyu Tang
>            Assignee: Chaoyu Tang
>            Priority: Minor
>             Fix For: 0.14.0
>
>         Attachments: HIVE-7445.patch
>
>
> Currently the error thrown when you cannot acquire a lock is:
> Error in acquireLocks... 
> FAILED: Error in acquiring locks: Locks on the underlying objects cannot be acquired.
retry after some time
> This error is insufficient if the user would like to understand what is blocking them
and insufficient from a diagnosability perspective because it is difficult to know what query
is blocking the lock acquisition.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message