[
https://issues.apache.org/jira/browse/SOLR-18405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18108417#comment-18108417
]
Eric Pugh commented on SOLR-18405:
----------------------------------
So, there is a cost to adding lambda, so we don't want to do it blindly, it
should be odne on "expense" logging calls, which, sigh, is of course a judgment
call.
> 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
> Priority: Minor
>
> 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]
