+1. To not using streams in hot paths.
Regarding string concatenation in logging, for debug and trace it makes sense
to avoid concatenation. For info and error I don't think it matters and it can
be more concise to concatenate. It's not a big deal to standardize on one just
because the extra ve
Definitely +1 on this. We saw in the early days of SAI development that
stream pipelines had a substantial impact on performance.
On Thu, 30 May 2024 at 19:28, Caleb Rackliffe
wrote:
> +1
>
> On Thu, May 30, 2024 at 11:29 AM Benedict wrote:
>
>> Since it’s related to the logging discussion we’r
+1
On Thu, May 30, 2024 at 11:29 AM Benedict wrote:
> Since it’s related to the logging discussion we’re already having, I have
> seen stream pipelines showing up in a lot of traces recently. I am
> surprised; I thought it was understood that they shouldn’t be used on hot
> paths as they are not
As a general statement I agree with you (same for String.format as well), but
one thing to call out is that it can be hard to tell what is the hot path and
what isn’t. When you are doing background work (like repair) its clear, but
when touching something internal it can be hard to tell; this c
Since it’s related to the logging discussion we’re already having, I have seen
stream pipelines showing up in a lot of traces recently. I am surprised; I
thought it was understood that they shouldn’t be used on hot paths as they are
not typically as efficient as old skool for-each constructions
The two-part proposal of 1.) table-level self-identification of
experimental status and 2.) a global config flag that determines what to do
when querying those might work. I guess the only thing you can't do there
is ignore warnings from a specific experimental table, since that's
controlled in cod
> Alex, just want to make sure that I understand your point correctly. Are you
> suggesting this sequence of operations with TCM?
>
> * Make config changes
> * Do the initial data copy
> * Make destination part of write placements (same as source)
> * Start destination instance
> * Decommission t
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
I'd like us to invest in unit tests and make them the contract guards.
>
Thank you Jacek.
In the end, I feel we strayed off the topic a bit - my question was quite
> concrete - I'd like to remove the CASSANDRA_USE_JDK11 knob for CCM - it
> should set it appropriately for Cassandra 4 so that the
> 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 ({}).
10 matches
Mail list logo
