[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324531#comment-15324531
]
Stefan Podkowinski edited comment on CASSANDRA-7622 at 6/10/16 2:34 PM:
------------------------------------------------------------------------
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. A lot of 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.
was (Author: [email protected]):
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)
