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 <calebrackli...@gmail.com> wrote: > > 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 why... > > Given this has always been an advanced feature, I'm neutral on adding > anything to NEWS.txt. > > On Mon, Apr 4, 2022 at 8:46 AM Ekaterina Dimitrova <e.dimitr...@gmail.com > <mailto:e.dimitr...@gmail.com>> wrote: > 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_bytes_per_ip. > While on startup if those parameters are set to something <= 0, they will get > a default value, their setters are not guarded in the same way, we just set > any long value. > I checked and this is actually something going on all currently supported > Cassandra versions. From there Caleb raised the question that 0 actually can > be a valid value and the check needs to cover possibly only < 0. > As these are advanced and non-documented parameters, I thought it is valuable > to confirm the course of action here. Especially, if we are willing to do a > change to all released versions. > So the proposal is to: > 1) change the check on startup from <=0 to <0 and make 0 a valid value, for > all versions? > 2) Add the same checks&assignment to the respective setters > 3) Update NEWS.txt explicitly (this part is a bit weird to me as we keep it > not advertised in cassandra.yaml but we want whoever uses it to know about > such changes...) > > Looking forward to your feedback, thanks in advance. > > Best regards, > Ekaterina
