So my suggestion from what I hear
- reject anything below -1.
- -1 points to the default.
- >=0 being valid.
- Done for both startup and the setters.
- Done only on trunk for now and I will add comment in Config instead of
NEWS.txt due to their hidden nature.
So my understanding is that 0 and 1 w
I am good with making >= 0 valid in both setters and config parsing, negatives
should error or produce defaults
> On Apr 4, 2022, at 10:45 AM, Caleb Rackliffe wrote:
>
> I'm for making >= 0 valid in both the setters and on startup. In the setters,
> I'm fine with either translating negative va
I'm for making >= 0 valid in both the setters and on startup. In the
setters, I'm fine with either translating negative values to the default
calculated value based on heap size or simply rejecting negative values. If
we really want to override that value, we had better have a really good
idea of w
Hi everyone,
While working on CASSANDRA-17431 to move the advanced Config parameters we
don't advertise in cassandra.yaml to the new types created in
CASSANDRA-15234, we ran into some concerns around
native_transport_max_concurrent_requests_in_bytes
and native_transport_max_concurrent_requests_in_b
