[
https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468316#comment-16468316
]
Shawn Heisey edited comment on SOLR-11453 at 5/9/18 4:41 AM:
-------------------------------------------------------------
New version of the informational patch. Summary of things different from your
patch:
* SolrCore main javadoc added as already mentioned.
* The requestLog field has no need to be public. Set to private.
* Removed string concatenation from logging messages, switched to slf4j \{\}
parameters. A bunch of concatenation for things other than slf4j logging still
exists.
* Removed most usages of isXxxxEnabled logging level checks.
* Added serialVersionUID to an anonymous class. Hopefully the number that
eclipse generated matches the one that Java auto-assigned. Prior experience
shows that having eclipse generate this value on a class always makes the same
number, so I think there's a possibility that it is indeed the same number that
Java assigns at compile time if it's not present. I actually have no idea
whether this is flagged as a warning by anything other than my IDE. If we
leave serialVersionUID out of a class that implement Serializable, then change
the code in that class in a way that changes the automatically generated
serialVersionUID, different versions of Solr will not be able to send/receive
that object in Javabin.
I kept one isDebugEnabled usage for a situation where a logging parameter comes
from a method that builds a string with StringBuilder instead of using already
built objects -- could be slow. Also added TODO on that to figure out whether
logging the same info at DEBUG and INFO is actually necessary.
I have plans to try and create a log4j config that uses a sysprop to decide
whether to log slow requests to a separate file, but it's not something that I
expect to come together quickly. I will likely need to learn groovy, since I
don't think we want slow javascript code running for every single log message.
I also need to figure out whether adding groovy as a dependency for Solr will
cause issues with the parts of the build system that already use groovy.
was (Author: elyograg):
New version of the informational patch. Summary of things different from your
patch:
* SolrCore main javadoc added as already mentioned.
* The requestLog field has no need to be public. Set to private.
* Removed string concatenation from logging messages, switched to slf4j \{\}
parameters. A bunch of concatenation for things other than slf4j logging still
exists.
* Removed most usages of isXxxxEnabled logging level checks.
* Added serialVersionUID to an anonymous class. Hopefully the number that
eclipse generated matches the one that Java auto-assigned. Prior experience
shows that having eclipse generate this value on a class always makes the same
number, so I think there's a possibility that it is indeed the same number that
Java assigns at compile time if it's not present.
I kept one isDebugEnabled usage for a situation where a logging parameter comes
from a method that builds a string with StringBuilder instead of using already
built objects -- could be slow. Also added TODO on that to figure out whether
logging the same info at DEBUG and INFO is actually necessary.
I have plans to try and create a log4j config that uses a sysprop to decide
whether to log slow requests to a separate file, but it's not something that I
expect to come together quickly. I will likely need to learn groovy, since I
don't think we want slow javascript code running for every single log message.
I also need to figure out whether adding groovy as a dependency for Solr will
cause issues with the parts of the build system that already use groovy.
> Create separate logger for slow requests
> ----------------------------------------
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
> Issue Type: Improvement
> Components: logging
> Affects Versions: 7.0.1
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
> Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch,
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for
> slow queries. Currently it is not possible to do this cleanly, because the
> WARN level used by slow query logging within the SolrCore class is also used
> for other events that SolrCore can log. Those messages would be out of place
> in a slow query log. They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been
> set up for request logging. In the SolrCore class, which is
> org.apache.solr.core.SolrCore, there is a special logger at
> org.apache.solr.core.SolrCore.Request. This is not a real class, just a
> logger which makes it possible to handle those log messages differently than
> the rest of Solr's logging. I propose setting up another custom logger
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
