[
https://issues.apache.org/jira/browse/SOLR-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hrishikesh Gadre updated SOLR-7683:
-----------------------------------
Attachment: SOLR-7683.patch
[~andyetitmoves] Please find the updated patch.
In case of DirectXmlRequest, we don't know the actual type of request until
after the object is created (and hence the value can not be hardcoded). Also
since existing clients/applications may be using this class, it may not a good
idea to enforce the requirement to specify a type. Hence may be we should keep
"Unspecified" type for backwards compatibility?
The other thing is we need to make sure that for server <-> server
communication, we are using the "server" context. Since we are creating
HttpSolrClient instances at number of places, we need to figure out a good way
to implement this. I propose that we should use a factory pattern for this.
i.e. we should define two factory implementations each dedicated for a specific
use-case (e.g. as a client or as a server) and refactor the code to use them
appropriately. This may involve considerable amount of refactoring. But the
resulting code would be clean and extensible for future requirements.
Any thoughts?
> Introduce support to identify Solr internal request types
> ---------------------------------------------------------
>
> Key: SOLR-7683
> URL: https://issues.apache.org/jira/browse/SOLR-7683
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Hrishikesh Gadre
> Assignee: Ramkumar Aiyengar
> Attachments: SOLR-7683.patch, SOLR-7683.patch
>
>
> SOLR-7344 is introducing support to partition the Jetty worker pool to
> enforce the number of concurrent requests for various types (e.g.
> Internal_Querying, Internal_Indexing, External etc.). For this we need to
> identify requests sent between Solr servers and their types (i.e.
> Querying/Indexing etc.).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
