OK thank you Josh. Nobody seems to object system property hence property
into jvm-server.option it will be.
Regards
On Wed, Nov 20, 2024 at 4:08 PM Štefan Miklošovič
wrote:
> These are all good questions ...
>
> BTW technically it would not be in cassandra.yaml. I understand system
> property t
These are all good questions ...
BTW technically it would not be in cassandra.yaml. I understand system
property to be a property you set to JVM upon it' start. It is not a
configuration property in yaml - It might go to jvm-server.options.
I would say that if that system property is set then it
> What do you think should happen with this newly-introduced system property in
> trunk? Removing it mercilessly in the trunk without any deprecation?
Is there a risk to leaving it in? I get the added complexity of having yet
another system property in that insane .yaml file, but having multiple
Happy to leave the dynamic setting of this in runtime out and go with a
good old system property in each patch release from 4.0.x to 5.0.x if it is
enough for people. We would deprecate alter_table_enabled in 5.0.x and
remove it in trunk with the introduction of CASSANDRA-19556.
What do you think
> they have to turn off a node, set the property and turn it back on. This is
> not optimal
We have quite a few other features that have this same paradigm to
disable/enable them. Is there a reason it's worse in this case than those, at
least on the 4.0 release? Users will have to bounce up to t
Hello,
I am having a little bit of a hard time delivering (1). Long story short,
this was aimed to be added to 5.0 but we postponed it because it was too
late so the new target is 5.1.
What we planned to do is to (2) deprecate alter_table_enabled in 5.0.1
which is superseded by CASSANDRA-19556, t
