[jira] [Commented] (SOLR-4019) Service Unavailable errors not being logged

["Commit Tag Bot (JIRA)" <ji...@apache.org>]

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

Commit Tag Bot commented on SOLR-4019:
--------------------------------------

[branch_4x commit] James Dyer
http://svn.apache.org/viewvc?view=revision&revision=1405894

SOLR-4019:  Log 503 stack traces unless from PingRequestHandler.  Suppress logging some stack traces with ShowFileRequestHandler.

                
> Service Unavailable errors not being logged
> -------------------------------------------
>
>                 Key: SOLR-4019
>                 URL: https://issues.apache.org/jira/browse/SOLR-4019
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Tomás Fernández Löbbe
>            Assignee: James Dyer
>            Priority: Minor
>             Fix For: 4.1, 5.0
>
>         Attachments: SOLR-4019.patch, SOLR-4019.patch
>
>
> Due to changes introduced in SOLR-2124, Service Unavailable (503) errors intentionally not logged. This was introduced to avoid the PingRequestHandler to generate exceptions in logs for requests that are not really exceptions for Solr, see http://www.gossamer-threads.com/lists/lucene/java-dev/171982 The problem with this now is that in some cases (like when using SolrCloud), 503 are critic problem and an exception should be logged. 
> Per hoss comment:
> {quote}
> The crux of the problem historically, and how we got into the weird
> situation with the Ping handler is that we wnat to return to the *client*
> the 503, so we threw an exception that would propogate up and result in
> SolrDispatchFilter returning the 503 -- but in the meantime we had to jump
> through a bunch of hoops to deal with the logging because for *solr* it's
> not really an error and we shouldn't freak out about logging. (ie: we want
> the client to know there is an 503 error, but on the server we don't
> relaly care.
> and the hoops we've jumped through for logging are now hurting us in a
> differnet situation where the 503 really is a serious problem.
> We have a similar situation in the ShowFileHandler where we want the
> *client* to ge a 404 error, so we throw a SolrException witha 404 error,
> but as a result Solr logs loud and ugly that a 404 error happened.
> I *think* the cleanest way to deal with this now, would be to change
> PingRequestHandler and ShowFileRequestHandler so that instead of
> *throwing* a SolrException, their handleRequest methods just construct a
> new SolrException with the appropraite status code, put that exception in
> the SolrQueryResponse, and then return.  I _think_ that would ypass
> the loud conspicous logging that currently happens when exceptions are
> thrown (and would let us remove the "ignore SERVICE_UNAVAILABLE
> exceptions" kludge that is huring us in SolrCloud so those exceptions
> would be logged loud and conspicuously)
> This type of solution is something that we *might* have been able to do
> along time ago except that it would have been complicated because of the
> different code paths arround writting successful output using hte response
> writers vs delegating error responses to the servlet container -- but now
> it doesn't matter, we use the response writters either way, so i *think*
> itwould be relatively striaght forward (although there may be some
> vestigal "oh no, we found an exception, we must log it" logic in the
> request dispatcher that might need to be tweaked to only do that if the
> exception is *thrown* and not just an object in the response)
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org