My $0.02... Options from best to worst:
1.) Use double when possible (chopping off non-sig-digs after the decimal if you want) 2.) Complain loudly that we would have to round and error out. ----------line of acceptable behavior---------------------------- 1000000.) Round silently ;) On Mon, Jul 18, 2022 at 9:26 AM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > > Hi everyone, > In 4.0 stream_throughput_outbound_megabits_per_sec and > inter_dc_stream_throughput_outbound_megabits_per_sec > were introduced. > It was requested all data rate parameters to support mebibytes/s, > kibibytes/s and bytes/s with the new config in 4.1 but to support backward > compatibility. This is in place but there is one outstanding question I > wanted to discuss with the community. As we know, converting between > megabits and mebibytes produces double numbers which we already handle > internally. Now, the question is how do we want to handle this in > JMX/nodetool when reporting to the users. The new getters in mebibytes will > be reporting in double to the users (I have a patch for that as we just > added the mebibytes flags in nodetool for stream_throughput_outbound and > inter_dc_stream_throughput_outbound > in 4.1). > I guess changing the getters to report double now will be a breaking > change so the options I see: > - we throw an error if we cannot report integer (the property was set in > mebibytes not megabits) and ask the users to check the mib versions and > report only integers > - We document there can be a loss of precision and people should be > looking into the mib one which will report exact numbers > > I guess I would prefer option 1 as people can easily miss anything > documented. > > Similar is the question for the Settings Virtual Table, but I guess there > we can switch all to double reporting or set to NA in case the old > properties (in megabits/s) are not integers. > > Best regards, > Ekaterina >
