[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324531#comment-15324531 ]
Stefan Podkowinski commented on CASSANDRA-7622: ----------------------------------------------- bq. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational perspective and be 100% worth it by itself. [~rustyrazorblade], as much as I share your aversion towards JMX, I'm not really sure a lot of ops people would even notice this new feature as long as we don't pull the plug on JMX. All existing monitoring solutions are based on JMX (which indirectly includes solutions on top of jolokia) and I don't expect a lot of enthusiasm among vendors to adopt virtual tables instead. So JMX will be here to stay, which begs the question who we have in mind for this feature? Just starting with a simplified, non-replicated, read-only version of virtual tables is also raising some red flags for me. We should be able to at least answer how advanced use cases could be implemented based on the current query execution model. If we can't, virtual tables are probably just a dead end road for any further steps we want to take to improve operational aspects. > Implement virtual tables > ------------------------ > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Reporter: Tupshin Harper > Assignee: Jeff Jirsa > Fix For: 3.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)