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> 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 >
