Hi Mick, I returned to this after some time and here are my questions about this.
I am waiting for 16806 to be merged which introduces abstract mutable vtables (1) on top of which I want to build what you have proposed. I do not think we need a non-virtual table for this and this is actually super handy in this case because we can react on updates / inserts / deletes and subscribe / unsubscribe an event to DiagnosticsService while modifying that vtable. Otherwise, I do not see an easy and straightforward way to react to our modifications to that table (maybe via QueryHandler but that is quite cumbersome and not too performance friendly). The question I have is rather semantic one. If we enable / disable events via this table, a user will suddenly have two ways to subscribe - via JMX and by CQL. Is this ok? If one subscribes via JMX, this subscription is not propagated to the underlying CQL table. So she might subscribe to 5 events but there would be none in vtable. On the other hand, if we subscribe via CQL, that will populate some maps in DiagnosticsService / DiagnosticsPersistence. Hence, my concern is about having this discrepancy between what we see in vtable and what is enabled via JMX path. How would you address this? Regards (1) https://github.com/apache/cassandra/pull/1117/files On Sat, 24 Jul 2021 at 18:59, Mick Semb Wever <m...@apache.org> wrote: > > > > > I am not sure yet how the implementation in case of virtual tables > > fits into the overall picture of "pluggability". > > > > Yeah, it was a goal of the design to make writing new types as easy as > possible, so having to wire up a new vtable for each new event type works > against that. > > I'd be inclined to start with just two tables: one "diagnostic_events" that > lists all events, and another "diagnostic_service" which lists what's > enabled (and allows you to enable them live). With the design of > Diagnostic Events as subscribe and pull, it would make sense (to me) if > enabling an event class in the diagnostic_service table ('update > diagnostic_service set enabled = true where class = '<event_name>') then > also does a subscribesAll with a noop consumer. > > Extending/configuring the limit makes sense as part of the binlog > implementation. I'm hesitant about allowing users to increase the in-memory > store. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
