JMX is really a toy metric system and comes with potential security concerns that have to be considered and managed over time.
The cost in the case you are seeing has also been potentially much worse in the past - a variety of expensive metrics are now cached I believe - but as it iterated over each objects metrics it would rapidly gather all of the metrics for the object once for each metric the object had. If you had many large cores, each with many index files for example, this was not good to say the least. I would certainly not want to be exposed to these types of things when I was not using the metrics or using the more scalable and logical metrics api. [Mark Miller - Chat @ Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=1dg8vz) [1dg8vz] On January 9, 2022 at 22:46 GMT, David Smiley <[email protected]> wrote: I noticed Solr auto-creates a metrics SolrJmxReporter if there is a platform "MBeanServer" that exists, which AFAICT is always. Thanks? Ehh, no thanks. It's not evident how to disable JMX after some fruitless google searches. Don't get me wrong, I like jconsole, jvisualvm, JFR etc and I think some of these things may rely on JMX but I don't particularly need Solr to expose its metrics to these tools ever since Solr gained pretty excellent /admin/metrics support that is easier to get at. I see Solr's code that makes this decision in SolrXmlConfig.getMetricReporterPluginInfos and I could see that I could enhance it with a few lines of code to check pluginInfo.isEnabled(). Thus to disable JMX reporting, one would configure it with the enable="false" XML attribute. Or maybe we just remove the automatic enablement. BTW what's driving me to look at this is that there is some time spent registering and unregistering SolrCore level metrics to JMX when SolrCores are loaded and unloaded, and logs to this effect likewise. Not a big deal but it's something. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
