[
https://issues.apache.org/jira/browse/SOLR-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-4019.
------------------------------
Resolution: Fixed
committed.
Trunk: r1405893
4x: r1405894
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
