Erick Erickson created SOLR-14349:
-------------------------------------
Summary: Upgrade to slf4j 2x when available and encourage using
lambdas for expensive methods called in log statements.
Key: SOLR-14349
URL: https://issues.apache.org/jira/browse/SOLR-14349
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Log4j2 already supports lazily-evaluated lambda expressions, but slf4j won't
support them until slf4j-2.0.0, see:
[https://jira.qos.ch/browse/SLF4J-371|https://jira.qos.ch/browse/SLF4J-371.].
(thanks M. Drob for finding this!)
Why it matters:
A line like *log.trace("stuff {}", object.someMethod())* will execute
object.someMethod() regardless of the log level, leading to unnecessary work.
One example is SOLR-12353.
Uwe Schindler pointed out that in the log4j2 context, constructs like:
*log.info("stuff {}", () -> object.someMethod(param))* are evaluated lazily,
i.e. the *object.comeMethod(param)* method is called if (and only if) the log
level includes "INFO".
Until slf4j2.0 comes out, we'll handle these expensive calls on a case-by-case
basis, the simplest way is to wrap expensive calls in an if clause, e.g. *if
(log.isTraceEnabled)* *\{log.trace....}*. Ugly, but it works. Once we can
upgrade to slf4j2.0, we should encourage using lambdas for any expensive method
call that's part of a log message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
