[
https://issues.apache.org/jira/browse/SOLR-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15955498#comment-15955498
]
Christine Poerschke commented on SOLR-10415:
--------------------------------------------
+1 to the idea.
Also, from memory the parameterized log message have (or perhaps had) a limit
on how many args can follow the first arg but this can be overcome e.g. like
this:
{code}
log.debug("calling waitForLeaderToSeeDownState for coreZkNodeName={}
collection={} shard={}", new Object[]{coreZkNodeName, collection, slice});
{code}
Also wondering, once the code is cleaned up, could something similar to the
forbidden-apis check be used to prevent the re-introduction of unparameterized
debug/trace log messages?
----
In the meantime, there are many debug and trace level logging statements, if
any particularly stood out in your samplings, perhaps we could start here by
changing those?
> Within solr-core, debug/trace level logging should use parameterized log
> messages
> ---------------------------------------------------------------------------------
>
> Key: SOLR-10415
> URL: https://issues.apache.org/jira/browse/SOLR-10415
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Michael Braun
> Priority: Trivial
>
> Noticed in several samplings of an active Solr that several debug statements
> were taking decently measurable time because of the time of the .toString
> even when the log.debug() statement would not output because it was
> effectively INFO or higher. Using parameterized logging statements, ie
> 'log.debug("Blah {}", o)' will avoid incurring that cost.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
