[
https://issues.apache.org/jira/browse/SOLR-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783004#comment-17783004
]
Ilan Ginzburg commented on SOLR-10466:
--------------------------------------
I believe that in the {{main}} branch, {{MiniSolrCloudCluster.shutdown()}}
closing all {{CloudSolrClient}} referenced in {{solrClientByCollection}} does
not work as expected under some conditions.
It uses a {{Collection.parallelStream()}} that might or might not use multiple
threads.
When it does not and closes the {{CloudSolrClient}} instances one by one in
sequence using the calling thread, all is well.
When it goes parallel it uses threads from the {{ForkJoinPool}} executor. These
threads are not allowed to shut down the {{notifications}} executor service in
{{ZkStateReader}} and throw a {{{}java.security.AccessControlException: access
denied ("java.lang.RuntimePermission" "modifyThread"){}}}.
Proper closing of {{ZkStateReader}} is not done and other resources are left
lingering. Tests pass but the {{ObjectReleaseTracker}} then complains for the
class.
I don’t know what triggers the parallel vs sequential choice in
{{{}parallelStream(){}}}. It doesn’t seem to happen on existing tests (that is
why I believe we don’t see this issue) but I do observe it on additional tests
I’m running on a fork of SolrCloud.
By replacing {{parallelStream()}} by an explicit use of a {{ForkJoinPool}}
executor, I am able to reproduce the problem with tests that otherwise pass
cleanly (for example {{TestTaskManagement.testCancellationQuery()}} or tests in
{{{}CurrencyRangeFacetCloudTest{}}}, {{CleanupOldIndexTest}} and many others,
maybe any test that calls {{{}MiniSolrCloudCluster.getSolrClient(String
collectionName){}}}?).
To see the issue, in {{{}MiniSolrCloudCluster.shutdown(){}}}, replace the
following code (sorry I untidied it):
{code:java}
solrClientByCollection.values().parallelStream()
.forEach(c -> { IOUtils.closeQuietly(c); });
{code}
With:
{code:java}
ForkJoinPool forkJoinPool = new ForkJoinPool(4);
for (CloudSolrClient c : solrClientByCollection.values()) {
forkJoinPool.submit(() -> { IOUtils.closeQuietly(c); },
ForkJoinPool.commonPool());
}
{code}
If anybody more knowledgeable than I am on these topics can shed some light on
the behavior of {{{}parallelStream(){}}}. In the meantime maybe we should just
remove that call?
FYI [~epugh]
> 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
