Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Tue, 30 Oct 2012 15:17:08 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: "dev@lucene.apache.org" <dev@lucene.apache.org>
Subject: RE: Service Unavailable exceptions not logged
In-Reply-To: 
 <8F0D0142CA7ECC4287A9EC1BD8CB880C182D6076BD@USLVDCMBVP01.ingramcontent.com>
Message-ID: <alpine.DEB.2.02.1210301504230.16684@frisbee>
References: 
 <CAMJgJxTOr0drKiA3Zqix79ntPqGam+GVzPkLkCn5BRYZwXqy_w@mail.gmail.com>
 <8F0D0142CA7ECC4287A9EC1BD8CB880C182D607509@USLVDCMBVP01.ingramcontent.com>
 <CAMJgJxQ1UThE3qezdVdzHFbrfwa8j1ky7Wi0bZkdy9_gz_8BzQ@mail.gmail.com>
 <8F0D0142CA7ECC4287A9EC1BD8CB880C182D6076BD@USLVDCMBVP01.ingramcontent.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org