[jira] [Work logged] (KNOX-2095) Many errors (E.G. 504s) being masked as 500 errors

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot logged work on KNOX-2095:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 05/Nov/19 20:56
            Start Date: 05/Nov/19 20:56
    Worklog Time Spent: 10m 
      Work Description: jameschen1519 commented on pull request #177: [WIP] KNOX-2095 - Adding in DefaultDispatch code and tests to handle 504 er…
URL: https://github.com/apache/knox/pull/177
 
 
   …rors
   
   (It is very **important** that you created an Apache Knox JIRA for this change and that the PR title/commit message includes the Apache Knox JIRA ID!)
   
   ## What changes were proposed in this pull request?
   
   Currently, Knox masks all connection errors as 500 errors, when they may be more accurately described using other error codes, especially 504. A change has been made to display a 504 error in the event of a socket timeout..
   
   (Please fill in changes proposed in this fix)
   
   ## How was this patch tested?
   
   Ran ant verify under Knox 1.2.0. The patch was generated against the Knox 1.2.0 branch, and subsequently applied to Knox 1.4.0. Currently ant verify is failing, but these are most likely transient errors as the same errors appear in master. Still running tests.
   
   (Please explain how this patch was tested. For instance: running automated unit/integration tests, manual tests. Please write down your test steps as detailed as possible)
   (If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)
   
   Please review [Knox Contributing Process](https://cwiki.apache.org/confluence/display/KNOX/Contribution+Process#ContributionProcess-GithubWorkflow) before opening a pull request.
   
 
----------------------------------------------------------------
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:
users@infra.apache.org


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

            Worklog Id:     (was: 338994)
    Remaining Estimate: 167h 50m  (was: 168h)
            Time Spent: 10m

> Many errors (E.G. 504s) being masked as 500 errors
> --------------------------------------------------
>
>                 Key: KNOX-2095
>                 URL: https://issues.apache.org/jira/browse/KNOX-2095
>             Project: Apache Knox
>          Issue Type: Improvement
>    Affects Versions: 1.2.0, 1.3.0
>            Reporter: James Chen
>            Assignee: James Chen
>            Priority: Minor
>              Labels: easyfix
>             Fix For: 1.4.0
>
>         Attachments: KNOX-2095.patch, jamchen504patch.patch
>
>   Original Estimate: 168h
>          Time Spent: 10m
>  Remaining Estimate: 167h 50m
>
> When errors occur while accessing the Knox gateway, errors are forcibly overridden and represented as 500 errors, rather than whatever errors they should be.
> For example, when the timeout value under gateway.httpclient.socketTimeout is set to a very low timeout value (E.G. 1 ms) under gateway-site.xml, a socket timeout exception is produced by the getHttpClient().execute( outboundRequest) call. However, this is caught by the surrounding try-catch block and thrown again as an IOException. This results in a generic 500 error, rather than a 504 error one would normally expect from this sort of interaction.
>  
> For these sorts of scenarios, I believe it would be prudent to create a dummy HttpResponse using a HttpResponseFactory object for the inboundResponse with the corresponding error code (E.G. HttpStatus.SC_GATEWAY_TIMEOUT in the event of a SocketTimeoutException) and return that instead to trigger the appropriate 504 error. I suspect there are other sorts of potential error code triggers that get this same IOException treatment that would be better off receiving their own error codes.
>  
> Judging from the source code, this issue likely affects version 1.3.0, though this has not been tested.



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