[
https://issues.apache.org/jira/browse/CASSANDRA-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158953#comment-13158953
]
Brandon Williams commented on CASSANDRA-3527:
---------------------------------------------
bq. Is this supposed to be a complete replacement for JMX? And if so, how
realistic is that without regressions? Will it support operations? Will it
return all of the attributes, even the complex types?
I think a *complete* replacement is aiming too high initially (see the last
sentence of this paragraph, though.) I think attributes you'd typically want
to read plus the few that nodetool can poke will go a long way toward removing
most of the pain. As far as types, the simple ones jconsole supports is
probably most of what we'd need, and we've already gone to some lengths to make
things jconsole-callable (accepting hostname strings instead of InetAddresses
being one example.) I poked around some mbeans where I thought I'd find an
example of a complex type, but the best one I found was handling a long[] for
the histograms.
bq. How will it be implemented? Are we going to have to edit the grammar each
time we add new instrumentation? If it's not a complete replacement, then are
we going to have to update/create the MBean interfaces and update the grammar?
What I had in mind is adding a new verb handler that would ask the (possibly
remote) node "give me o.a.c.foo" and the remote node would get/find the
corresponding mbean and send the result back over MS. That way we only have to
deal with the mbean interfaces as usual, and grammar would just have a 'some
kind of mbean path' parameter that it wouldn't need to do any checking on, and
then 'some kind of parameters' that the node could compare to its own signature
for 'o.a.c.foo' to know if it was ok.
bq. If it's not meant to be a complete replacement, then how will this not
contribute to there being even more ways getting at the same data?
I think Kelley made a good point that being able to do everything with a single
interface is much friendlier than the current state. It will be Yet Another
Way, sure, but I think a unified interface will help drive adoption.
bq. I've never looked at it closely, but we added hooks for using an HTTP
adapter with mx4j specifically to address this issue. Does anyone know why that
hasn't caught on?
Probably because the majority of people don't know it's there, we don't include
the jars by default. I guess we could solve this and then clever client
wrappers could add convenience methods to handle the needed HTTP stuff, but
then we're moving away from "the cql driver does everything you want" mindset
and are back to wrappers.
> Expose JMX values via CQL interface
> -----------------------------------
>
> Key: CASSANDRA-3527
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3527
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Kelley Reynolds
> Priority: Minor
> Labels: cql
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
