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
> As another option, we could add an @Experimetal annotation (or another name)
> and a configuration parameter experimental_virtula_tables_enabled
Since these are tables we have TableProps so we could always store an
experimental = true there and if Config.experimental_virtula_tables_enabled ==
I think that 2) (client warning on accessing vtable) is pretty obtrusive /
irritating, that means that every single time I would e.g. SELECT from such
a table, it would emit a warning to a client / cqlsh? I do not think that
is necessary.
What about putting such a table to system_experimental keys
Hello everyone,
I like the idea of highlighting some of the experimental virtual
tables whose model might be changed in future releases.
As another option, we could add an @Experimetal annotation (or another
name) and a configuration parameter
experimental_virtula_tables_enabled (default is false
I agree that ClientWarning is the best way to indicate the risk of using an
experimental feature directly to the user. Presenting information in the client
application's logs directly means that the person who wrote the query is most
likely to see the warning, rather than an operator who sees cl
We agreed a long time ago that all new features are disabled by default, but I
wanted to try to flesh out what we “should” do with something that might still
be experimental and subject to breaking changes; I would prefer we keep this
thread specific to vtables as the UX is different for differe
Hi,
+1 on CCM not using CASSANDRA_USE_JDK11 to pick a JDK version. I don’t think
it’s a good interface for expressing what JDK CCM should use. I checked and I
don’t see it being used in the dtests, so it shouldn’t break anything? I am not
sure what it was added for.
Cleaning up CCM so it only
> This is exactly the feedback I was looking for, the last thing we want to
> do is reduce the throughput of the already strained CI pipelines.
>
> Sounds like it's a bigger task than just cutting over to ARM, just want to
> reassure you Brandon we certainly won't change anything without discussion
10 matches
Mail list logo
