[
https://issues.apache.org/jira/browse/SOLR-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042136#comment-17042136
]
Andrzej Bialecki commented on SOLR-14274:
-----------------------------------------
[~mdrob] yeah, that comment is wrong - it doesn't skip, it overwrites the
metric instances that are under the same names.
Regarding the "force: true" argument: Dropwizard's default behavior is to
refuse re-registering an already existing metric. However, Solr must be able to
forcefully replace existing metric instances, and this situation occurs
frequently and it's not exceptional, so it should not cause exceptions. This
happens eg. when a new SolrIndexSearcher is created, or a core is reloaded -
many metrics (specifically, Gauge metrics) are really lambdas tied to the old
instances, and the new instances logically belong under the same names - so it
makes sense to always forcefully replace the old values with the new ones.
So if a change is needed to streamline our code I'd go the opposite way - make
the "force: true" the default behavior in SolrMetricManager.
> Multiple CoreContainers will register the same JVM Metrics
> ----------------------------------------------------------
>
> Key: SOLR-14274
> URL: https://issues.apache.org/jira/browse/SOLR-14274
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mike Drob
> Priority: Major
>
> When running multiple CoreContainer in the same JVM, either because we called
> {{SolrCloudTestCase.configureCluster(int n)}} with {{n > 1}} or because we
> have multiple tests running in the same JVM in succession, we will have
> contention on the shared JVM {{metricsRegistry}} as they each replace the
> existing metrics with their own. Further, with multiple nodes at the same
> time, some of these metrics will be incorrect anyway, since they will only
> reflect a single core container. Others will be fine since I think they are
> reading system-level information so it doesn't matter where it comes from.
> I think this is a test-only issue, since the circumstances where somebody is
> running multiple core containers in a single JVM in production should be
> rare, but maybe there are edge cases affected with EmbeddedSolrServer and
> MapReduce or Spark, or other unusual deployment patterns.
> Removing the metrics registration entirely can speed up
> {{configureCluster(100).build()}} on my machine from 2 minutes to 30 seconds,
> so I'm optimistic that there can be gains here without sacrificing the
> feature entirely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
