[
https://issues.apache.org/jira/browse/CASSANDRA-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564738#comment-17564738
]
Ekaterina Dimitrova commented on CASSANDRA-17725:
-------------------------------------------------
{quote}...perhaps you could have imagined a case for zero where the clock
didn't advance, and you would have been able to load the first table in the
while body, but that seems pretty esoteric.
{quote}
That's what I was thinking but figured that the world of Cassandra is always
surprising me so better to check also with reviewer/authors. I will take care
of the converter
{quote}bq. Why don't we just simplify things and leave MiB/s values as doubles
everywhere?
{quote}
While it is tempting, I think it might be confusing for the end users. They
can't be setting double numbers but they are getting some and only for the
mebibytes version. Also, we cannot switch to doubles for the megabits which are
4.0-addition properties and they will still suffer of that problem. This is
also an issue with the bulk loader that [~frankgh] fights. In theory I would
expect/recommend people to set and get with the same unit, but the practice is
different - someone will come and just use the first getter they see to check
values...
I started wondering whether we should not make those flags bytes and not
mebibytes and internally those properties also can be operated in bytes. It
will also automatically solve the Settings Virtual table (the precision there)
as a side effect. But he issue is that people will have to input quite big
numbers and they can make mistakes, MiB/s was not chosen randomly I think.
{quote} - Given we're going to a new major version, did we really have to
change {{MiB}} back to {{MB}} in [this
commit|https://github.com/ekaterinadimitrova2/cassandra/commit/92e0c3948fc65b29fbe289814f84aaf603188152]?
Even if someone was parsing tool output, they still would only break if they
explicitly validated "MB" rather than just making sure to take the numeric
value, right?{quote}
I would personally keep the MiB but after all latest discussions I would prefer
to revert it and just use it in the description, if you don't mind :)
{quote} - Two things on {{{}"i", "stream_throughput_mib"{}}}. First, is the
normal pattern to use hyphens instead of underscores for the long form? Second,
given this is a modifier on the default argument, why not just use something
like {{{}"m", "mib"{}}}?{quote}
Good catch, definitely hyphens. I like the idea of switching to "mib" and "m",
I will change this.
{quote} - In the {{MEGABITS_TO_MEBIBYTES_PER_SECOND_DATA_RATE}} JavaDoc,
"megatibs" -> "megabits"?
- There's enough in common that it might be nice to combine
{{SetGetInterDCStreamThroughputMiBTest}} and
{{SetGetInterDCStreamThroughputTest}} into a single
{{{}InterDCStreamThroughputConfigTest{}}}. (Same goes for the non-inter-DC
versions.){quote}
Will include in the PR tomorrow, thanks
> 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]
