[
https://issues.apache.org/jira/browse/SOLR-14423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089798#comment-17089798
]
Andrzej Bialecki commented on SOLR-14423:
-----------------------------------------
Fair enough :) {{SolrCloudManager}} was an effort to separate SolrCloud from
Zookeeper API, and it succeeded in the autoscaling APIs that are now completely
ZK agnostic - it would be a monumental task to completely switch Solr to using
its APIs instead of ZK, but it is used in a few other places too, even in some
handlers (MetricsHistoryHandler, AutoscalingHandler). It's easy to mock or
provide alternative implementations / delegates in tests, and it has the
above-mentioned ObjectCache. Conversely, it's very difficult to mock a
CoreContainer properly.
But I agree it's specific to SolrCloud. I'm worried that if you add this map to
CC then it will become much harder to simulate / mock this in tests, because
you will always need to instantiate a CoreContainer.
(If we had a proper dependency injection framework many of these crutches
wouldn't be necessary ... but that's another discussion.)
> static caches in StreamHandler ought to move to CoreContainer lifecycle
> -----------------------------------------------------------------------
>
> Key: SOLR-14423
> URL: https://issues.apache.org/jira/browse/SOLR-14423
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
> Reporter: David Smiley
> Priority: Major
>
> StreamHandler (at "/stream") has several statically declared caches. I think
> this is problematic, such as in testing wherein multiple nodes could be in
> the same JVM. One of them is more serious -- SolrClientCache which is
> closed/cleared via a SolrCore close hook. That's bad for performance but
> also dangerous since another core might want to use one of these clients!
> CC [~jbernste]
--
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
