+1 to using Markers, and to Josh's & Benedict's points.
Logs have defined semantics, redefining them is confusing. To be completely
honest, I wasn't even consciously aware of the convention that DEBUG would be
used for background logs. I don't expect most users would be either.
On 2024/07/3
I reckon we could start using slf4j/logback Markers to tag individual logging
statements as foreground/background (or, ideally, with more granularity than
that - separate out repair, compaction, schema, reads/wrties, etc.).
> On 24 Jul 2024, at 16:02, Josh McKenzie wrote:
>
> I argued this poi
I argued this point 6 years ago and I'll continue to argue it today. Relying on
assertions in production code by default, having debug live in production code
by default, these are code and culture smells to me. Yes we work on complex
distributed systems. No we should not be relying on crutches
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
On Tue, 23 Jul 2024 at 15:27, J. D. Jordan
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 a
>
> I do not agree we should remove isDebugEnabled tests, as debug logging
> should be possible to turn off and avoid any penalty.
>
if (logger.isDebugEnabled())
logger.debug("hello")
is performance-wise same as doing
logger.debug("hello")
we already went through this, the latter version in
1) That is not the current state of the code;
2) We should anyway not be codifying something just because a handful of people
have been doing it.
C-10241 does not accord with this view either - it makes clear the debug log
output should be for "where we can log things that might help if somethin
I don't know what consists of "too crazy" in your books. It would look same
as it is now after we removed isTracingEnabled. Maybe going through the
opening email and seeing the reasoning why, similarly, isDebugEnabled is
not always necessary would be helpful?
On Tue, Jul 23, 2024 at 3:27 PM J. D.
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 description of the log levels from the old wiki describes the state of our logging very well, +1 to get that back into the docs.If someone wants to
For the record, I am OK with removing logger.isDebugEnabled() in the same
spirit as it was done with logger.isTracingEnabled(). That is, some
invocations of isDebugEnabled() are not necessary, logger.debug() is just
enough, I already went through the reasons why it is so in the first email
from whi
> I disagree with all of this. Debug logging *can* be enabled for
> production clusters, but it should not be on by default.
>
> DEBUG should *not* be taken to mean “background activities” and we should
> stamp this out wherever this has been occurring. DEBUG means verbose
> logging for use debuggi
I disagree with all of this. Debug logging can be enabled for production
clusters, but it should not be on by default.
DEBUG should not be taken to mean “background activities” and we should stamp
this out wherever this has been occurring. DEBUG means verbose logging for use
debugging system be
reply below…
On Thu, 30 May 2024 at 14:34, Štefan Miklošovič
wrote:
> I see the feedback is overall positive. I will merge that and I will
> improve the documentation on the website along with what Benedict suggested.
>
I think the codestyle needs to be more explicit that this applies _only_
I see the feedback is overall positive. I will merge that and I will
improve the documentation on the website along with what Benedict suggested.
On Thu, May 30, 2024 at 10:32 AM Mick Semb Wever wrote:
>
>
>
>> Based on these findings, I went through the code and I have incorporated
>> these rul
> Based on these findings, I went through the code and I have incorporated
> these rules and I rewrote it like this:
>
> 1) no wrapping in "if" if we are not logging more than 2 parameters.
> 2) rewritten log messages to not contain any string concatenation but
> moving it all to placeholders ({}).
The if test beforehand should only be done if the log invocation is expected to
do unnecessary work, eg construct a varargs array or do some costly string
translation as part of the parameter construction to the log statement.
I would not want to encode as prescriptive list as the one proposed a
> I saw a lot of cases like this:
>
> if (logger.isTraceEnabled())
> logger.trace("a log message");
>
> and sometimes just:
>
> logger.trace("a log message");
>
> Why do we do it once like that and another time the other way?
I remember years ago seeing perf numbers where the i
There is a ticket I have a mental block to merge (1). The way it happened
is that in CASSANDRA-19429 a user identified that there is a logging
statement which acquires a lock which slows down query execution. When
reworked, under CASSANDRA-19429, a reporter saw ridiculous performance
gains on machi
18 matches
Mail list logo
