lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-11453) Create separate logger for slow requests
Date Wed, 09 May 2018 04:42:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message