[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561476#comment-17561476
]
Ekaterina Dimitrova commented on CASSANDRA-17725:
-------------------------------------------------
interdcstreamthroughput flags added in this
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/d5e7134c99e5e938b74c2ad74fbf2c916f0785ce]
and streamthroughput flag added in this
[commit|https://github.com/ekaterinadimitrova2/cassandra/commit/9c6e1452a939ad5420daa5eefce33ac5b6e050ec]
The only thing I am wondering here is how to handle that nodetool and the
StorageService JMX methods are rounding to int and 0 very small values in
megabits to MiB/s (the getters in MiB, when we provide too small megabits) I
added in nodetool a check that will say instead of unlimited - 1 MiB/s. I plan
to document that when you use one or the other unit you should use the
respective setter/getter as otherwise you might see that side effect. Seeing 0
in MiB - someone might decide that they are unthrottling when in reality they
have super low value in megabits internally. What do others think about this?
I had a few findings which I addressed in separate commits:
* [several changes in
output|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]
- I tried instead to clarify the unit in the description
*
[cassandra.yaml|https://github.com/ekaterinadimitrova2/cassandra/commit/153ccb6dfff630b2229bbcc5c92d201e5e5d2616]
- there were a few parameters which were commented for testing and that was
not reverted. It doesn't break anything as then we are using the same default
value which is in DatabaseDescriptor but it is not needed change and makes it
confusing for the users
* I believe this
[withBufferSizeInMB|https://github.com/ekaterinadimitrova2/cassandra/commit/d16170fd6a15f2ec20acd057e8f44ec5ded39094]
method had to be deprecated and not just removed
And a few topics I am adding for discussion:
-
[https://github.com/apache/cassandra/commit/5bb4bab12f8edfef95ed13cbabf8c0f377986065#diff-f7dd0237c343649f70b7ec9fefd7f6941a40b5164fd6063dce00fc09d2c234a7L163-R163]
- method which is not exposed by the mbean but it is public; is this a
breaking change?
*
[https://github.com/apache/cassandra/commit/c51a7c66fc21ca2da08b89ae5f9b4817ee4d8c23#diff-2314788f556b14ab8cd9c4cf4eba04f4b292f0b9c93d74919eed33a0af42ababL279-L280]
—> breaking change?? - I doubt it but double-checking. I can revert it just to
be on the safe side
And a bug I found that I want to ask [~jolynch] for advise as he was involved
into adding that property:
[https://github.com/apache/cassandra/commit/9f56bf4ca7fdb61ad09e5f2ad09b87cd01e0716b#diff-77707d0908c31940828b6425dcb09a7409827db99b48c371f71c63294dfe1562L444-R444]
—> please check, I believe this change is a bug. The Converter used for that
property with the pre-4.0 format does not allow negatives and we will always
have 0 in AutoSavingCache where we check for negatives and not 0. The test
where this was set to -1 is testKeyCacheLoadZeroCacheLoadTime and it works
without an issue with 0. . For [~jolynch] - long story short we prohibited the
usage of negatives as it was considered a bug in 4.1. But it seems different
here with this property. If negatives and 0 will do the same (I am not sure,
didn’t dive too much into that patch), maybe we can use the
_NEGATIVE_SECONDS_DURATION_ converter from the Converters class we added for
validation_preview_purge_head_start which will convert a negative number to 0
in 4.1 and tell people from now on will use 0 to disable but at the same time
if they upgrade with negative and the old value format and property name, they
will be able to set negative number which will be migrated internally to 0. I
am really not completely sure, what do others think?
CI running here for the 4.1 branch:
[j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1767/workflows/5f62f5d2-0930-4084-9031-61e1087b22fb],
[j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1767/workflows/781c87d6-9ea1-45ad-838e-53e0d9ee50ee]
[~maedhroz] , [~dcapwell] , [~mck] , can I ask you for review, please?
> Add a flag for throughput in MiB/s for nodetool setstreamthroughput,
> getstreamthroughput, setinterdcstreamthroughput and
> getinterdcstreamthroughput
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17725
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
> Reporter: Ekaterina Dimitrova
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> As we agreed not to add new JMX methods for the new config on the mailing
> list, we need at least new flags for setstreamthroughput and
> interdcstreamthroughput for the two 4.0 parameters to be set/get also in MiB,
> not only in megabits.
> Thus we will have the option either to use the old version for those 2, or to
> be able to set/get in MiB all 4 streaming parameters. As of 4.1 supported
> units for DataRateSpec are MiB/s, B/s, KiB/s, megabit is only for legacy from
> 4.0 - backward compatibility.
> To be sure we satisfy the requirements around the latest discussions about
> backward compatibility in tools, I will use this ticket also to make a final
> pass on the unit changes done, to ensure the probe output is not affected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
