[
https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077438#comment-17077438
]
Stephen Mallette commented on CASSANDRA-15582:
----------------------------------------------
In an effort to continue with what I referred to as a one-time test in my
previous comment, I've continued tinkering with the groovy script I'd written.
I adjusted it to connect to two separate running instances of Cassandra so as
to compare the JMX metrics of each. Here's the core substance of the script to
see the specifics of what it's doing - I've added comments which contain some
analysis of my findings so far:
{code:java}
import javax.management.ObjectName
import javax.management.remote.JMXConnectorFactory as JmxFactory
import javax.management.remote.JMXServiceURL as JmxUrl
server4Url = 'service:jmx:rmi:///jndi/rmi://localhost:7199/jmxrmi'
server4 = JmxFactory.connect(new JmxUrl(server4Url)).MBeanServerConnection
query = new ObjectName('org.apache.cassandra.metrics:*')
allNames4 = server4.queryNames(query, null)
server3Url = 'service:jmx:rmi:///jndi/rmi://localhost:7200/jmxrmi'
server3 = JmxFactory.connect(new JmxUrl(server3Url)).MBeanServerConnection
query3 = new ObjectName('org.apache.cassandra.metrics:*')
allNames3 = server3.queryNames(query3, null)
// While there are definitely metrics that are registered in 3.11.6 that are
not in 4.0
// the difference seems bound not to the "name" of the metrics but to other
property keys
// associated outside of that one. For example, in 3.x there is a "scope" key
of:
//
// scope=views_builds_in_progress
//
// which in 4.0 is:
//
// scope=view_builds_in_progress
//
// and seems related to CASSANDRA-12245. So, if the concern here is mostly with
just
// metric names and not other property keys shifting then we can at least
confirm that
// all the metric names in 3.x are at least still available in 4.x. If there
are concerns
// about documenting changes like the "scope" example from above then some more
work would
// need to be done to identify those.
metricNamesIn3NotIn4 = allNames3.collect{it.getKeyProperty('name')}.unique().
findAll{it3 -> !allNames4.collect{it4 ->
it4.getKeyProperty('name')}.any{it4 -> it4 == it3}}
assert metricNamesIn3NotIn4.size() == 0
// For those metrics that exist in 3.x and are registered in 4.x, I wanted to
see if any
// of those metrics changed in an incompatible way which meant that pure
equality checks
// on the MBeans themselves wouldn't work so well because 4.x could have added
something
// new which would not create a breaking condition. We would only have such
trouble if
// all the attributes, operations, notifications, and constructors defined in
3.x were
// somehow not represented in 4.x in the same way and thus required individual
comparison
// on equality.
//
// While there were definitely new attributes, operations, notifications, and
constructors
// added in 4.x it does not appear as though any breaking changes occurred in
that way.
metricIn3And4DiffAtr = allNames3.findAll{ server4.isRegistered(it) }.findAll{
m3 = new GroovyMBean(server3, it)
m4 = new GroovyMBean(server4, it)
attrs3 = m3.info().attributes
attrs4 = m4.info().attributes
ops3 = m3.info().operations
ops4 = m4.info().operations
nots3 = m3.info().notifications
nots4 = m4.info().notifications
cons3 = m3.info().constructors
cons4 = m4.info().constructors
!(attrs3.size() <= attrs4.size() && attrs3.every{it3 -> attrs4.any{it4 ->
it4.equals(it3) }} &&
ops3.size() <= ops4.size() && ops3.every{it3 -> ops4.any{it4 ->
it4.equals(it3) }} &&
nots3.size() <= nots4.size() && nots3.every{it3 -> nots4.any{it4 ->
it4.equals(it3) }} &&
cons3.size() <= cons4.size() && cons3.every{it3 -> cons4.any{it4 ->
it4.equals(it3) }})
}
assert metricIn3And4DiffAtr.size() == 0
{code}
Assuming I haven't missed something important, this initial body of analysis
seems to indicate that there isn't widespread breaking change in JMX for 4.x.
I'm still staring at all this to determine what else might be tested or if I've
missed something important in this initial work. I'm happy to hear if any of
this is interesting or helpful (or if I'm on the completely wrong track to what
is desired here). If not, I'll assume I should just continue on this track of
analysis and continue to post findings.
Also, I'm not sure if anyone has had a moment to look but I still do have an
improvement to unit tests for metrics that could use some review if someone has
the chance to take a look:
[https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15582-trunk-batchmetrics]
> 4.0 quality testing: metrics
> ----------------------------
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
> Reporter: Josh McKenzie
> Assignee: Romain Hardouin
> Priority: Normal
> Fix For: 4.0-rc
>
>
> In past releases we've unknowingly broken metrics integrations and introduced
> performance regressions in metrics collection and reporting. We strive in 4.0
> to not do that. Metrics should work well!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
