lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe <>
Subject Re: Service Unavailable exceptions not logged
Date Wed, 31 Oct 2012 13:03:07 GMT
I created

On Tue, Oct 30, 2012 at 7:17 PM, Chris Hostetter

> : Possibly better is introduce yet one more overloaded constructor with a
> : boolean that suppresses logging and change PRH to use it.
> 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)
> -Hoss
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message