You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2015/06/13 23:33:01 UTC
[jira] [Comment Edited] (SOLR-7344) 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.
[ https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14584827#comment-14584827 ]
Mark Miller edited comment on SOLR-7344 at 6/13/15 9:32 PM:
------------------------------------------------------------
bq. I think the paths are hardcoded for internal traffic. Right?
The /update handler is hard coded in ConcurrentUpdateSolrServer. I don't think this is totally intentional currently - we allow much more expressive configuration. I don't think it's a bad idea to lock down a known /update handler, but I think we are still in fuzzy territory in terms of decisions on that. The query side should not be hardcoded, you can use shard.qt or something to change the internal handler that is hit.
bq. I guess another approach would be to have SolrHttpClient always pull out certain parameters and put them on the URL, even for POST requests.
These names are confusing, but that's the feature I mention above.
I guess more interesting would be if we could move that impl from HttpSolrClient to the Solr HttpClient created by HttpClientUtil (currently returns an CloseableHttpClient impl). I don't know offhand how feasible that is though.
(which is what I assume you meant by SolrHttpClient?)
was (Author: markrmiller@gmail.com):
bq. I think the paths are hardcoded for internal traffic. Right?
The /update handler is hard coded in ConcurrentUpdateSolrServer. I don't think this is totally intentional currently - we allow much more expressive configuration. I don't think it's a bad idea to lock down a known /update handler, but I think we are still in fuzzy territory in terms of decisions on that. The query side should not be hardcoded, you can use shard.qt or something to change the internal handler that is hit.
bq. I guess another approach would be to have SolrHttpClient always pull out certain parameters and put them on the URL, even for POST requests.
These names are confusing, but that's the feature I mention above.
I guess more interesting would be if we could move that impl from HttpSolrClient to the Solr HttpClient created by HttpClientUtil (currently returns an CloseableHttpClient impl). I don't know offhand how feasible that is though.
> 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
> Attachments: SOLR-7344.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org