Eric Pugh created SOLR-18405:
--------------------------------
Summary: Adopt SLF4J 2.x lazy-argument-evaluation logging on hot
paths
Key: SOLR-18405
URL: https://issues.apache.org/jira/browse/SOLR-18405
Project: Solr
Issue Type: Improvement
Components: logging
Reporter: Eric Pugh
Split off from SOLR-14349, which bundled "upgrade to SLF4J 2.x" (done —
currently on 2.0.18) with "encourage lambda-based lazy logging" (never adopted,
and too vague to close as-is).
SLF4J 2.x's fluent API (`log.atTrace().addArgument(() ->
expensiveCall()).log("...{}")`) defers evaluating a log argument until the
logger confirms the level is actually enabled. Today Solr's codebase uses none
of it — the standing pattern is the manual guard clause:
```java
if (log.isTraceEnabled()) {
log.trace("stuff {}", object.someExpensiveMethod());
}
```
repeated 127+ times in `solr:core` alone. This is functionally correct but easy
to get wrong (it's simple to add a new `log.trace(...)`/`log.debug(...)` call
with an expensive argument and forget the guard) — SOLR-12353 is a documented
case of exactly that causing a real performance regression.
**Proposed scope**, to keep this actionable rather than an open-ended
"encourage" task:
1. Audit call sites where a logging argument does non-trivial work (method
calls, string concatenation/formatting, stream operations) and isn't already
guarded — start with `solr:core`'s hottest request-handling paths (`SolrCore`,
`RequestHandlerBase`, `SolrIndexSearcher`, update processors).
2. Convert the worst offenders to the SLF4J 2.x fluent lazy-argument style.
3. Consider whether a Forbidden-APIs or ErrorProne rule could flag *new*
unguarded expensive-argument log calls at `trace`/`debug` level going forward,
so this doesn't silently regress again — this would need care to avoid false
positives on cheap arguments (plain field reads, string literals).
Not proposing a mechanical find-and-replace across the whole codebase — most
existing guard clauses aren't costing anything meaningful. This should be
scoped to genuinely hot/expensive call
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
