You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Mike Drob (Jira)" <ji...@apache.org> on 2020/03/05 18:50:00 UTC

[jira] [Commented] (SOLR-14274) Multiple CoreContainers will register the same JVM Metrics

    [ https://issues.apache.org/jira/browse/SOLR-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17052427#comment-17052427 ] 

Mike Drob commented on SOLR-14274:
----------------------------------

[~ab] - gentle ping on this, would be interested to know what you think of this PR.

> 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
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org