[jira] [Comment Edited] (HIVE-19380) Hive Lock Error Message Too Verbose

["BELUGA BEHR (JIRA)" <ji...@apache.org>]

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

BELUGA BEHR edited comment on HIVE-19380 at 5/3/18 1:34 PM:
------------------------------------------------------------

This is logging that is presented to the client.  The client may be a data engineer, data scientist, business intelligence user.... none of these roles need to see a long Java stack trace.  It is meaningless to them and just scary/confusing.  We should keep the stack-trace in the HS2 application logs, for the cluster admins, but a helpful, human-readable, error message is going to be the best thing to present to the end user.

 

Perhaps printing the stack trace is a 'beeline' thing, in which case the fix should hopefully be trivial.


was (Author: belugabehr):
This is logging that is presented to the client.  The client may be a data engineer, data scientist, business intelligence user.... none of these roles need to see a long Java stack trace.  It is meaningless to them and just scary/confusing.  We should keep this in the HS2 application logs, but a helpful, human-readable, error message is going to be the best thing to present to the end user.

 

Perhaps printing the stack trace is a 'beeline' thing, in which case the fix should be hopefully trivial.

> Hive Lock Error Message Too Verbose
> -----------------------------------
>
>                 Key: HIVE-19380
>                 URL: https://issues.apache.org/jira/browse/HIVE-19380
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2, Locking
>    Affects Versions: 3.0.0, 2.4.0
>            Reporter: BELUGA BEHR
>            Priority: Minor
>
> When a query fails to gain a lock to a table, the following error message appears in beeline.  The error message does not need a stack trace and it would be helpful to know how long it waiting before it gave up.  It should also state exactly which lock it was unable to obtain.
> {code:java}
> ERROR : FAILED: Error in acquiring locks: Locks on the underlying objects cannot be acquired. retry after some time
> org.apache.hadoop.hive.ql.lockmgr.LockException: Locks on the underlying objects cannot be acquired. retry after some time
>         at org.apache.hadoop.hive.ql.lockmgr.DummyTxnManager.acquireLocks(DummyTxnManager.java:171)
>         at org.apache.hadoop.hive.ql.Driver.acquireLocksAndOpenTxn(Driver.java:1205)
>         at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1489)
>         at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1285)
>         at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1280)
>         at org.apache.hive.service.cli.operation.SQLOperation.runQuery(SQLOperation.java:236)
>         at org.apache.hive.service.cli.operation.SQLOperation.access$300(SQLOperation.java:89)
>         at org.apache.hive.service.cli.operation.SQLOperation$3$1.run(SQLOperation.java:301)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:415)
>         at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1920)
>         at org.apache.hive.service.cli.operation.SQLOperation$3.run(SQLOperation.java:314)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:745)
>  {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)