[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14494749#comment-14494749
]
Ramkumar Aiyengar commented on SOLR-7344:
-----------------------------------------
No separate threadpools: For very small solr clouds, it might just be overkill
or just sit there without being used at all (what if I had only one replica?)
Per request type: I might want to dedicate separate amount of resources to say,
indexing and searching, so that one doesn't starve out the other. In indexing
spikes, you can currently visibly see search performance be affected on
leaders..
On the ZK layout, I guess this would work.. Just that I am in two minds about
if all this configuration should be in live nodes.. But happy to be convinced..
The alternative would be for the endpoint could just have a port and a name.
May be it could guarantee a "default" endpoint being always present. So live
nodes just "publishes" information about its resources, and how its "consumed"
is decoupled. SolrJ could just hard code the default name and allow people to
configure the end point name to start things off -- or this could be part of
separate per-coll config which SolrJ reads (isn't there a clusterprops.json? I
forget..) and that could store configuration for logically what each operation
should use. Similarly indexing config for Solr could allow for an endpoint to
be configured.
> Use two thread pools, one for internal requests and one for external, to
> avoid distributed deadlock and decrease the number of threads that need to be
> created.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
