[ 
https://issues.apache.org/jira/browse/HIVE-24772?focusedWorklogId=587236&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-587236
 ]

ASF GitHub Bot logged work on HIVE-24772:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 22/Apr/21 13:13
            Start Date: 22/Apr/21 13:13
    Worklog Time Spent: 10m 
      Work Description: belugabehr commented on pull request #1974:
URL: https://github.com/apache/hive/pull/1974#issuecomment-824830468


   @miklosgergely @pvary Are you able to review this as well?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 587236)
    Time Spent: 2h 50m  (was: 2h 40m)

> Revamp Server Request Error Logging
> -----------------------------------
>
>                 Key: HIVE-24772
>                 URL: https://issues.apache.org/jira/browse/HIVE-24772
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: David Mollitor
>            Assignee: David Mollitor
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Most of the action takes place in {{ThriftCLIService}} where errors are 
> logged in response to client requests (though I know in many instances things 
> are logged multiple times).
> I propose to improve this on multiple fronts:
> # Many log messages have the word "Error" in it, but log at the WARN level.  
> I have changed all relevant logging to be at ERROR level and removed the word 
> "Error" from the message
> # Some of the error message in the logging code had copy & paste errors where 
> they printed the wrong request name
> # Print the actual request object in the error message
> # Big one for me: Do not pass a stack trace to the client.  This is bad 
> practice from a security perspective,... clients should not know that level 
> of detail of the server, and also it's very confusing for the client 
> perspective to understand that the stack trace is actually from the remote 
> server, not the local client, and finally, it's too messy for a typical user 
> to deal with anyway.  Stack trace should be presented in the HS2 logs only.
> # Various clean up
> # Log an IP address for the client as part of standard operating procedure



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to