You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2011/06/22 17:50:47 UTC
[jira] [Created] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
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
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
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063382#comment-13063382 ]
Yonik Seeley commented on SOLR-2615:
------------------------------------
Thanks for the tips David, hopefully when SOLR-2616 is committed we can fix this oddity.
I've committed this patch to trunk and will backport.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053597#comment-13053597 ]
Yonik Seeley commented on SOLR-2615:
------------------------------------
bq. 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.
I think there is still a point to caching isDebugEnabled() though. The implementation most likely involves checking volatile variables, and can involve checking a hierarchy of loggers. I assume the cost may be different for different logging implementations too. Better to just cache if you can and not worry about 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
[jira] [Assigned] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley reassigned SOLR-2615:
----------------------------------
Assignee: Yonik Seeley
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "David Smiley (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "David Smiley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley updated SOLR-2615:
-------------------------------
Attachment: SOLR-2615_LogUpdateProcessor_debug_logging.patch
> 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
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "David Smiley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley updated SOLR-2615:
-------------------------------
Attachment: SOLR-2615_LogUpdateProcessor_debug_logging.patch
> 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.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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062003#comment-13062003 ]
Yonik Seeley commented on SOLR-2615:
------------------------------------
bq. Yonik, if I instead use a doDebug boolean flag initialized in the constructor, would that sufficiently satisfy you to commit this?
Yep, I think so...
> 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.4, 4.0
>
> 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
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "David Smiley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061467#comment-13061467 ]
David Smiley commented on SOLR-2615:
------------------------------------
Yonik, if I instead use a doDebug boolean flag initialized in the constructor, would that sufficiently satisfy you to commit this?
> 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.4, 4.0
>
> 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
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Bill Bell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062618#comment-13062618 ]
Bill Bell commented on SOLR-2615:
---------------------------------
If I use the DIH handler and turn on threads=2 I get more debugging output than if I don't use threads... It actually outputs EVERY add to Solr...
Is this something that should be fixes here too?
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "David Smiley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062674#comment-13062674 ]
David Smiley commented on SOLR-2615:
------------------------------------
Yonik,
In JDK14 logging, the console logger has a default threshold of INFO. This makes the out-of-the-box use of Solr's logging admin page a little deceiving since it more detailed logging appears to do nothing. To quickly configure the threshold, look at SOLR-2616 which includes a logging config file with a commented threshold adjustment.
Bill,
I'm not sure about the log output of the DIH with threads=2; it would appear to be specific to the DIH based on your description and unrelated to the files involved in this patch.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Resolved] (SOLR-2615) Have LogUpdateProcessor log each
command (add, delete, ...) at debug/FINE level
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley resolved SOLR-2615.
--------------------------------
Resolution: Fixed
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org