I wouldn't forbid isDebugEnabled.
Guarding heavy debug params with it makes perfect sense per se, you
avoid a perf penalty with 1 loc. If in C* production clusters are
expected/preferred to be run with debug logging on so be it but being an
OSS project we're unaware of all tools, side-projects and any other
consumers of our code. They could be benefiting from not running in debug.
Parsing the use of isDebugEnabled as making debug not meant for
production is sthg I am not totally following. Debug is, imo, is
perfectly fine in production for it's intended uses and with it's know
impact. If we want to signal we want C* to be ran in debug in production
then let's add a big warning in the logback xml files on even log that
as a WARN or ERROR. But I wouldn't push down that concern into the code
style.
Besides, imo, if we remove/forbid it getting it back if we changed our
minds wouldn't be an easy task. Whereas if it's there it doesn't hurt.
My 2cts
On 23/7/24 16:12, Mick Semb Wever wrote:
On Tue, 23 Jul 2024 at 15:27, J. D. Jordan <jeremiah.jor...@gmail.com>
wrote:
I don’t know that I agree we should remove use if isDebugEnabled,
but we should be assuming debug is enabled and not doing anything
too crazy there.
The problem is that the use of isDebugEnabled, as trivial as it is,
leads to the typical assumption that debug is not meant for
production. This has tripped us up in the past. It's important that
debug logging does not impact production performance. Any use of
isDebugEnabled is counter-intuitive to this. Maybe restoring the
logging guidelines is enough, but I'd argue that we can further
simplify things (at least against our current state of affairs) by
just disallowing the use of isDebugEnabled altogether.
And yes, debug equalling background tasks is not entirely accurate, my
bad (the doc provides a far more accurate description to what might be
found in system vs debug log files). And there's for example
read/write tracing, that if enabled, might only be found in the
debug.log . This has been brought up previously, and in the ticket
and old ml thread there's mention in keeping system.log clean to
read/writes/hotpaths. The logging guideline was written (by Paulo I
believe) as a result of 10241 and that old ml thread.
We have an existing logging guideline doc, we need debug to be
performant in production – it is enabled by default, and is designed
and recommended to be used in production.
