[
https://issues.apache.org/jira/browse/SOLR-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783349#comment-17783349
]
David Smiley commented on SOLR-10466:
-------------------------------------
Our security.policy and solr-tests.policy both have {{permission
java.lang.RuntimePermission "modifyThread";}}. And the grant isn't qualified
(filtered) to any codeBase or anything else, and thus it should apply to all
code Java is running. So I don't see why this problem would happen. I did
some googling on this and turned up [an interesting stack-overflow
post.|https://mail.openjdk.org/pipermail/core-libs-dev/2013-December/024044.html]
with a comment pointing to a relevant [JDK mailing list
post|https://mail.openjdk.org/pipermail/core-libs-dev/2013-December/024044.html].
The [javadocs on
ForkJoinPool|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ForkJoinPool.html]
confirm the root cause -- the default implementation when the SecurityManager
is set, has no permissions. I think the solution would be to pass a system
property "java.util.concurrent.ForkJoinPool.common.threadFactory" with a Solr
provided custom implementation that has the permissions.
> 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
