> Can be accomplished by updating or inserting on the settings virtual table via UPDATE system_views.settings SET value = 32 WHERE name = 'compaction_throughput';
Oh nice, I wasn't aware this was available already, this is a great feature to look forward to in 4.0! > There is a long way to deprecate JMX though, a lot of things are absolutely necessary before even considering it like https://issues.apache.org/jira/browse/CASSANDRA-14629 Thanks for the pointer Chris. Will put together a proposal based on input from this thread with a long term plan to slowly transition from JMX to virtual tables. <https://issues.apache.org/jira/browse/CASSANDRA-14629> Em seg., 19 de jul. de 2021 às 12:33, Chris Lohfink <clohfin...@gmail.com> escreveu: > > a) Allow VirtualTables to be settable - to support changing parameters > (ie. > > nodetool setcompactionthroughput 32). > > > Can be accomplished by updating or inserting on the settings virtual table > via > > UPDATE system_views.settings SET value = 32 WHERE name = > 'compaction_throughput'; > INSERT INTO system_views.settings (name, value) VALUES > ('compaction_throughput', 32); > > It also aligns configuration in yaml names with what you use to update it > at runtime, vs having different naming and one off commands for each > individual setting. That was pushed off in the settings virtual table for > post 4.0 however. (see original patch in > https://issues.apache.org/jira/browse/CASSANDRA-14573) > > There is a long way to deprecate JMX though, a lot of things are absolutely > necessary before even considering it like > https://issues.apache.org/jira/browse/CASSANDRA-14629 > > Chris > > On Fri, Jul 16, 2021 at 11:39 AM Aleksey Yeschenko <alek...@apache.org> > wrote: > > > I would say just go with it. JMX isn’t quite deprecated yet, and if we > > ever even end up doing that, it’s not going to be any time soon. > > > > > On 16 Jul 2021, at 13:32, Stefan Miklosovic < > > stefan.mikloso...@instaclustr.com> wrote: > > > > > > Thanks Benjamin for the understanding, but in the end, let's put aside > > > the frustration here, I think I can just kind of detach from that. > > > > > > However, in this particular case, I really think we should just finish > > > this and merge it and move on. By not doing so and waiting for the CEP > > > around this, we are just opening ourselves to a possibility that it > > > will not be finished / implemented and we will live without that > > > command. > > > > > > In other words, I just do not like to not do something, when it just > > > lies in front of me, just because of some assumption we make that > > > something will happen in the future. I do not get this approach. The > > > future might just change. Plus this is just an easy patch, no big > > > deal, it is not like I would have to revert the heaps of code to > > > accommodate future features. > > > > > > If I do not merge it, I am afraid this might happen: > > > > > > A user (lets call him Tommy), is excited about 4.0, they are using > > > some custom auditing and he wants to give a shot to native stuff we > > > provide here. So he goes and downloads, tries it, all is good. > > > Then he realises that it was a long time ago he set this up, messed > > > with that a bit and kept it running. But after a while, he forgot how > > > he set it up. So he looks into nodetool and sees, yay, enableauditlog, > > > disableauditlog, there are a bunch of get* commands too, but no status > > > of audit log? How can I know how that is set up? > > > > > > So Tommy reaches the community and says that hey, you are missing that > > > command, am I going to see it in 4.1 or in some patch release at least > > > to get it sooner? > > > > > > And we reply: > > > > > > Dear Tommy, > > > > > > we know it is missing, but wait! There is this CEP we are working day > > > and night on, it will solve the world hunger and it will be the best > > > thing since the sliced bread, you just have to wait a little bit > > > longer, because there are other things going on right now and it seems > > > to take longer than expected, lot of problems on the way, so maybe > > > return in 4.3 and there you get it. > > > > > > But Tommy does not care. He truly does not. He just wants to query the > > > state of the audit log by any means necessary. And once this happens > > > multiple times he just goes away. > > > > > > By the way, I really think this is a little bit more complicated than > > > it seems. It is hard to guess how the implementation will look like > > > but in our original discussion with Paulo, we were thinking about > > > having a completely separate repository for this where only the client > > > would be. There are few benefits - it might be just released > > > independently, if we truly separate this and we talk only CQL, I do > > > not see any reason why we should depend on the main Cassandra > > > repository. It also lowers the barrier for other people who would want > > > to implement the command they miss. However, I get that while we want > > > to support both approaches, it will be done and probably it has to be > > > done together, but I am afraid that we will just introduce a hybrid > > > which would take ages to finish fully so we can announce JMX > > > deprecated. There are a lot of commands to be migrated as well and > > > having a separate repository would at least make the main repo less > > > noisy. But since I am not fully aware of what approach we end up with > > > and how the implementation would look like in the end, I can not fully > > > advocate the separate repository approach because it might be just > > > rendered ineffective and wrong. > > > > > > That's just my rambling here but I would just close the issue with > > > 16725 by merging that and then we can fully focus on CEP and all > > > things related. > > > > > > Sounds good to everybody? > > > > > > Regards > > > > > > > > > On Fri, 16 Jul 2021 at 10:44, Benjamin Lerer <b.le...@gmail.com> > wrote: > > >> > > >> Thanks a lot for all the feedback, I really appreciate the discussion > > and > > >> Paulo's proposals. > > >> > > >> Regarding the ongoing patches: > > >> > > >> Based on the discussion, it clearly appears that nodetool will still > be > > >> there for some time (and will be there in the next major release). > > >> As such, it seems to me that the current ongoing patches to add new > > >> nodetool commands will be useful. > > >> I honestly do not see the point at this stage of preventing them from > > going > > >> in and I can totally understand the frustration of the people that > have > > >> spent time on making them. > > >> I did not trigger that discussion with that goal in mind. My goal was > > more > > >> to clarify our strategy for the future. > > >> > > >> It seems only fair to me to let these patches go in and simply thank > the > > >> contributors for their efforts and work. > > >> We can open some followup tickets for providing those functionalities > > >> through Virtual Tables (we are only talking about 2 patches). > > >> If nobody else takes them, I will. > > >> > > >> > > >> Le ven. 16 juil. 2021 à 10:17, Mick Semb Wever <m...@apache.org> a > > écrit : > > >> > > >>>> > > >>>>> Until CEP exists and is approved, work on patches in flight seems > > >>>> reasonable and valid. > > >>>> > > >>>> This is right, but when there is an active discussion about changing > > the > > >>>> status quo it's polite to wait for the outcome of the discussion - > or > > >>> help > > >>>> it make progress - before making potentially conflicting changes. > > >>>> > > >>> > > >>> > > >>> Totally agree. > > >>> This question has been asked many times, and is often getting > answered > > by > > >>> fragmented groups. The broader discussion is definitely warranted > > (thank > > >>> you Benjamin). > > >>> > > >>> Stefan, looking at the patch for CASSANDRA-16725, it is only intended > > for > > >>> trunk so it has 6 months to land. I'm definitely in favour of seeing > it > > >>> also be put into a vtable. It doesn't change the patch much, just an > > ask > > >>> for a trivial class to be added, and that is a reasonable request to > > make > > >>> through the review rounds. (A few rounds during the review like this > is > > >>> _perfectly normal_, and is only going to improve the patch in other > > areas, > > >>> like changing the code to use Config.PROPERTY_PREFIX and > > >>> CassandraRelevantProperties). > > >>> But I can take this feedback to the ticket. Also happy to help out > (as > > any > > >>> reviewer that makes a suggestion should be!) > > >>> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
