lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Updated] (SOLR-4019) Service Unavailable errors not being logged
Date Thu, 01 Nov 2012 15:11:12 GMT

     [ https://issues.apache.org/jira/browse/SOLR-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tomás Fernández Löbbe updated SOLR-4019:
----------------------------------------

    Attachment: SOLR-4019.patch

Updated patch. In the ShowFileRequestHandler I also avoid throwing the exception for the cases
where the file has been intentionally hidden.
I also think there is a bug in the log(Logger log, String msg, Throwable e) method of the
SolrException. The code is:

{code:java}
  public static void log(Logger log, String msg, Throwable e) {
    if (e instanceof SolrException
        && ((SolrException) e).code() == ErrorCode.SERVICE_UNAVAILABLE.code) {
      log(log, msg);
    }
    String stackTrace = msg + ':' + toStr(e);
    String ignore = doIgnore(e, stackTrace);
    if (ignore != null) {
      log.info(ignore);
      return;
    }
    log.error(stackTrace);
  }

  public static void log(Logger log, String msg) {
    String stackTrace = msg;
    String ignore = doIgnore(null, stackTrace);
    if (ignore != null) {
      log.info(ignore);
      return;
    }
    log.error(stackTrace);
  }
{code}

It looks like exceptions that are logged with this method and have the code 503 are going
to be logged twice (the second time with the stacktrace) where the intention was to only log
the message. This patch also removes that double logging.
                
> 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
>            Priority: Minor
>         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


Mime
View raw message