Overall I have similar thoughts and questions as David. I just wanted to add a reminder about this thread from last summer[1]. We already have issues with the alignment of JMX and Settings Virtual Table. I guess this is how Maxim got inspired to suggest this framework proposal which I want to thank him for! (I noticed he assigned CASSANDRA-15254)
Not to open the Pandora box, but to me the most important thing here is to come into agreement about the future of JMX and what we will do or not as a community. Also, how much time people are able to invest. I guess this will influence any directions to be taken here. [1] https://lists.apache.org/thread/8mjcwdyqoobpvw2262bqmskkhs76pp69 On Thu, 26 Jan 2023 at 12:41, David Capwell <dcapw...@apple.com> wrote: > I took a look and I see the result is an interface that looks like the > vtable interface, that is then used by vtables and JMX? My first thought > is why not just use the vtable logic? > > I also wonder about if we should care about JMX? I know many wish to > migrate (its going to be a very long time) away from JMX, so do we need a > wrapper to make JMX and vtables consistent? I am cool with something like > the following > > registerWithJMX(jmxName, query(“SELECT * FROM system_views.streaming”)); > > > So if we want to have a JMX view that matches the table then that’s cool > by me, but one thing that has been brought up in reviews is backwards > compatibility with regard to adding columns… If we add a column to the end > of the JMX row did we just break users? > > Considering that JMX is usually not used and disabled in production > environments for various performance and security reasons, the operator may > not see the same picture from various of Dropwizard's metrics exporters > > > If this is a real problem people are hitting, we can always add the > ability to push metrics to common systems with a pluggable way to add > non-standard solutions. Dropwizard already support this so would be low > hanging fruit to address this. > > To make the proposed changes backwards compatible with the previous > version of Cassandra, all MBeans and Virtual Tables we already have will > remain unchanged > > > If this is for new JMX endpoints moving forward, I am not sure of the > benefit for the same reason listed above; we wish to move away from JMX > > On Jan 25, 2023, at 10:51 AM, Maxim Muzafarov <mmu...@apache.org> wrote: > > Hello Cassandra Community, > > > I've been faced with a number of inconsistencies in the user APIs of > the internal data collections representation exposed through the > Cassandra monitoring interfaces that need to be fully aligned from an > operator perspective. First of all, I'm highlighting JMX, Dropwizard > Metrics, and Virtual Tables user interfaces. In order to address all > these inconsistencies, I have created a draft enhancement proposal > that describes everything I have found and how we can fix it once and > for all. > > I'd like to hear your opinion and thoughts on it. Please take a look: > > https://docs.google.com/document/d/1j4J3bPWjQkAU9x4G-zxKObxPrKg36jLRT6xpUoNJa8Q > > > -- > Maxim Muzafarov > > >
