[
https://issues.apache.org/jira/browse/SOLR-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783627#comment-17783627
]
Ilan Ginzburg commented on SOLR-10466:
--------------------------------------
I’ve inventoried uses of {{parallelStream()}} in the code (not limited to
{{{}.values().parallelStream(){}}}).
Here are the occurrences and my take on them:
* {{{}ZkController.preClose(){}}}, first occurrence: seems ok not attempting
any forbidden operation (calls {{{}ZkShardTerms.close(){}}}).
* {{{}ZkController.preClose(){}}}, second occurrence: calls
{{ReplicationHandler.shutdown()}} that does
{{{}ExecutorUtil.shutdownAndAwaitTermination{}}}. {*}{color:#de350b}I believe
it would fail if run on the ForkJoinPool{color}{*}.
* {{{}CoreContainer.pauseUpdatesAndAwaitInflightRequests(){}}}: looks ok
* {{{}MultiDestinationAuditLogger.audit(){}}}: looks ok
* {{{}ZkStateReader.close(){}}}: looks ok (counts down on a latch). Likely
counter productive to run on an executor vs current thread.
* {{{}AbstractFullDistribZkTestBase.destroyServers(){}}}, both occurrences
call {{{}IOUtils.closeQuietly(){}}}, {color:#de350b}*would likely fail*{color}.
* {{{}MiniSolrCloudCluster.shutdown(){}}}: *{color:#de350b}fails{color}* (in
custom tests triggering for some not understood reason the parallel behavior).
In tests, it's not justified IMO to try to configure the access rights of the
fork join pool threads to be able to do operations that are forbidden by
default. I would therefore remove the use in {{AbstractFullDistribZkTestBase}}
and {{{}MiniSolrCloudCluster{}}}.
In prod code, there's one problematic instance in
{{{}ZkController.preClose(){}}}. The parallel stream is for stopping
replication from leader cores. It makes sense to do these stops in parallel
(they do wait for executor termination in
{{{}ReplicationHandler.shutdown(){}}}).
I believe using a different {{Executor}} here (rather than add complex and
little known/understood {{ForkJoinPool}} configuration) would prove easier to
understand and maintain.
> setDefaultCollection should be deprecated in favor of SolrClientBuilder
> methods
> -------------------------------------------------------------------------------
>
> Key: SOLR-10466
> URL: https://issues.apache.org/jira/browse/SOLR-10466
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
> Reporter: Jason Gerlowski
> Assignee: Eric Pugh
> Priority: Minor
> Fix For: 7.0, main (10.0), 9.3
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> Now that builders are in place for {{SolrClients}}, the setters used in each
> {{SolrClient}} can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy"
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the
> {{setDefaultCollection}} setter on all {{SolrClient}} implementations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
