I created https://issues.apache.org/jira/browse/SOLR-4019
On Tue, Oct 30, 2012 at 7:17 PM, Chris Hostetter <[email protected]>wrote: > > : 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: [email protected] > For additional commands, e-mail: [email protected] > >
