[
https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062487#comment-13062487
]
Yonik Seeley commented on SOLR-2615:
------------------------------------
I was trying to test this patch (actually see what the new logging output
looked like) and when trying to change the log level from
http://localhost:8983/solr/admin/logging
I can't seem to get anything above the "INFO" level. For example, changing
"root" to SEVERE works to suppress messages at the INFO level, but changing it
to "FINEST" doesn't get me anything more than "INFO". Any clues?
> 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
> Assignee: Yonik Seeley
> Priority: Minor
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2615_LogUpdateProcessor_debug_logging.patch,
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
