Hi everyone, I just realized the email I have prepared to close this thread was never sent, staying still in my draft… So better later than never and apologize for that. Considering David’s response and that people didn’t express strong opinion, new setters were not added (you probably saw already but just confirming).
In regards to virtual tables and whether we want to continue adding JMX methods after CASSANDRA-15254 lands, I suggest we get back to this when it lands. I think it is still early but it is good to be raised as a topic so people can start forming opinion and giving feedback as the one David already shared, for example :-) Best regards, Ekaterina On Fri, 13 May 2022 at 13:29, David Capwell <dcapw...@apple.com> wrote: > s/I don’t feel its non-trivial/I feel its non-trivial/. > > Update support requires a good amount of testing, so isn’t as simple as > calling the existing setters (mostly defining a Function<String, > field.type> that works for callers for each complex type) > > > On May 13, 2022, at 10:26 AM, David Capwell <dcapw...@apple.com> wrote: > > CASSANDRA-15254 only adds support for updating, we already have support > for viewing (getter). The work to support mostly gets complicated for > complex types such as collections, so I don’t feel its non-trivial as we > have complex types in our config that has to be dealt with, so since there > isn’t a patch for this I am in favor of 4.2 here (wouldn’t want to rush > this patch). > > I am in favor of #1, for configs that need to expose a setter they already > exist, so do not need a new one. For configs that are not mutable they are > exposed via the settings table, so don’t think we need to add into 4.1 but > more than happy to have in 4.2 > > About your comment about supporting adding new JMX after > https://issues.apache.org/jira/browse/CASSANDRA-15254 lands… I am 100% in > favor of no longer adding unless the author really wants…. I wouldn’t want > to block, but am cool making it optional/discouraged in favor of the > settings table. > > About the v2 MBean… this makes things more complex to me, I rather have v2 > methods like we have been doing... > > On May 13, 2022, at 6:21 AM, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > Hi everyone, > > Code freeze started but I wanted to seek for community agreement on one > important topic. > > After CASSANDRA-15234 we have the new yaml format for duration, data > storage and data rate config parameters. > New JMX methods with the new format are created since then for new > parameters like guardrails for example. > > The old JMX methods for our config are still there so people can keep on > using them to set the parameters by only value with the old default units. > I opened a ticket for adding also JMX methods for the new value format but > it was not implemented so far in favor of > https://issues.apache.org/jira/browse/CASSANDRA-17562. > Unfortunately, https://issues.apache.org/jira/browse/CASSANDRA-17562 did > not land before the code freeze. > So my question is about the path forward and these are the options I see: > 1. Neither https://issues.apache.org/jira/browse/CASSANDRA-17562 or > CASSANDRA-15254 lands in this release. People still have the old JMX methods > 2. CASSANDRA-15254 lands as being just getters and setters, non-invasive > and quick but we will have to keep on supporting them or deprecate after > CASSANDRA-17562 lands in next release. The tricky part is that some of the > old JMX methods already have name without unit like getCasContentionTimeout > and we can't just change them and break compatibility > 3. CASSANDRA-17562 gets implemented > > 2. brings another important question. The moment CASSANDRA-17562 lands, do > we still want to add JMX? Shall we continue adding new getters/setters? > If the answer is "yes, we shall continue" and option 1, then I suggest we > deprecate methods like getCasContentionTimeout in this release in favor of > new ones with unit suffix so we can change those names to be used for the > new format with the next release. Otherwise, there was a suggestion we add > v2 StorageProxyMbean as this is where we see now problem. (Thanks Andres > for raising the point!) > > Best regards, > Ekaterina > > > >
