lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each command (add, delete, ...) at debug/FINE level
Date Thu, 23 Jun 2011 03:28:49 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053630#comment-13053630
] 

David Smiley commented on SOLR-2615:
------------------------------------

I traced the code from SLF4J thru JDK14 Logging and indeed there is a volatile-read at the
end.  I didn't see any hierarchy traversal.  Isn't this a bit of a micro-optimization concern?
 These log calls are on a per-indexed document basis, not a per-term/token or low level detail
basis.  My personal code taste eschews verbosity.

But I'm not going to fight it further, so if you still don't agree then I'm not going to object
to any log-level cache & check modifications when you commit it.

> Have LogUpdateProcessor log each command (add, delete, ...) at debug/FINE level
> -------------------------------------------------------------------------------
>
>                 Key: SOLR-2615
>                 URL: https://issues.apache.org/jira/browse/SOLR-2615
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 3.3
>
>         Attachments: SOLR-2615_LogUpdateProcessor_debug_logging.patch
>
>
> It would be great if the LogUpdateProcessor logged each command (add, delete, ...) at
debug ("Fine") level. Presently it only logs a summary of 8 commands and it does so at the
very end.
> The attached patch implements this.
> * I moved the LogUpdateProcessor ahead of RunUpdateProcessor so that the debug level
log happens before Solr does anything with it. It should not affect the ordering of the existing
summary log which happens at finish(). 
> * I changed UpdateRequestProcessor's static log variable to be an instance variable that
uses the current class name. I think this makes much more sense since I want to be able to
alter logging levels for a specific processor without doing it for all of them. This change
did require me to tweak the factory's detection of the log level which avoids creating the
LogUpdateProcessor.
> * There was an NPE bug in AddUpdateCommand.getPrintableId() in the event there is no
schema unique field. I fixed that.
> You may notice I use SLF4J's nifty log.debug("message blah {} blah", var) syntax, which
is both performant and concise as there's no point in guarding the debug message with an isDebugEnabled()
since debug() will internally check this any way and there is no string concatenation if debug
isn't enabled.

--
This message is automatically generated by JIRA.
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