[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-dev
Subject: Re: [DISCUSSION] CASSANDRA-17562 and CASSANDRA-15254; future of JMX and Virtual tables
From: Ekaterina Dimitrova <e.dimitrova () gmail ! com>
Date: 2022-06-21 18:55:08
Message-ID: CAN+t3-g6OoY+AVUxV27cT_F5mKDn-Mtq72xrkJQvw7ejJXT85Q () mail ! gmail ! com
[Download RAW message or body]
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 <dcapwell@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 <dcapwell@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.dimitrova@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
>
>
>
>
[Attachment #3 (text/html)]
<div dir="auto">Hi everyone,</div><div dir="auto"><br></div><div dir="auto">I just \
realized the email I have prepared to close this thread was never sent, staying still \
in my draft…</div><div dir="auto">So better later than never and apologize for \
that.</div><div dir="auto">Considering David's response and that people didn't \
express strong opinion, new setters were not added (you probably saw already but just \
confirming).</div><div dir="auto"><br></div><div dir="auto">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 :-) </div><div \
dir="auto"><br></div><div dir="auto">Best regards,</div><div \
dir="auto">Ekaterina</div><div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Fri, 13 May 2022 at 13:29, David Capwell <<a \
href="mailto:dcapwell@apple.com">dcapwell@apple.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div \
style="word-wrap:break-word;line-break:after-white-space">s/I don't feel its \
non-trivial/I feel its non-trivial/.<div><br></div><div>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)</div></div><div \
style="word-wrap:break-word;line-break:after-white-space"><div><br><div><br><blockquote \
type="cite"><div>On May 13, 2022, at 10:26 AM, David Capwell <<a \
href="mailto:dcapwell@apple.com" target="_blank">dcapwell@apple.com</a>> \
wrote:</div><br><div><div \
style="word-wrap:break-word;line-break:after-white-space">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).<div><br></div><div>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</div><div><br></div><div>About your \
comment about supporting adding new JMX after <a \
href="https://issues.apache.org/jira/browse/CASSANDRA-15254" \
target="_blank">https://issues.apache.org/jira/browse/CASSANDRA-15254</a> 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.</div><div><br></div><div>About the v2 MBean… this makes things more complex \
to me, I rather have v2 methods like we have been doing...<br><div><br><blockquote \
type="cite"><div>On May 13, 2022, at 6:21 AM, Ekaterina Dimitrova <<a \
href="mailto:e.dimitrova@gmail.com" target="_blank">e.dimitrova@gmail.com</a>> \
wrote:</div><br><div><div dir="auto">Hi everyone,<br></div><div \
dir="auto"><br></div><div dir="auto">Code freeze started but I wanted to seek for \
community agreement on one important topic.</div><div dir="auto"><br></div><div \
dir="auto">After CASSANDRA-15234 we have the new yaml format for duration, data \
storage and data rate config parameters.</div><div dir="auto">New JMX methods with \
the new format are created since then for new parameters like guardrails for \
example.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">I opened a ticket for adding \
also JMX methods for the new value format but it was not implemented so far in favor \
of <a href="https://issues.apache.org/jira/browse/CASSANDRA-17562" \
target="_blank">https://issues.apache.org/jira/browse/CASSANDRA-17562</a>.</div><div \
dir="auto">Unfortunately, <a \
href="https://issues.apache.org/jira/browse/CASSANDRA-17562" \
target="_blank">https://issues.apache.org/jira/browse/CASSANDRA-17562</a> did not \
land before the code freeze.</div><div dir="auto">So my question is about the path \
forward and these are the options I see:</div><div dir="auto">1. Neither <a \
href="https://issues.apache.org/jira/browse/CASSANDRA-17562" \
target="_blank">https://issues.apache.org/jira/browse/CASSANDRA-17562</a> or \
CASSANDRA-15254 lands in this release. People still have the old JMX \
methods</div><div dir="auto">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</div><div dir="auto">3. \
CASSANDRA-17562 gets implemented </div><div dir="auto"><br></div><div dir="auto">2. \
brings another important question. The moment CASSANDRA-17562 lands, do we still want \
to add JMX? Shall we continue adding new getters/setters?</div><div dir="auto">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!)</div><div \
dir="auto"><br></div><div dir="auto">Best regards,</div><div \
dir="auto">Ekaterina</div> \
</div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic