[
https://issues.apache.org/jira/browse/SOLR-14274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046294#comment-17046294
]
Andrzej Bialecki commented on SOLR-14274:
-----------------------------------------
{quote}I'm looking at this with replacing the idea of a binary force flag with
an enum dictating what to do in case of conflict - replace, skip, or fail.
{quote}
Makes sense, although it could make the code more complex ... let's see how it
looks like, perhaps we could provide overloaded methods with the default
behavior of replace (since that's the most common case)?
> 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
