[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14561532#comment-14561532
]
Hrishikesh Gadre commented on SOLR-7344:
----------------------------------------
[~yo...@apache.org]
I have an alternate proposal similar to your earlier idea of having a logical
partition of a jetty worker pool without requiring a separate endpoint. I
believe this would also solve the problem of request forwarding.
The idea here is to implement a custom Servlet filter similar to [Jetty
QoSFilter|http://www.eclipse.org/jetty/documentation/current/qos-filter.html]
which would reserve a certain capacity of the worker thread-pool for internal
and external requests. The advantages of this approach are as follows,
- We will still get to use the thread-per-request model when the number of
requests (of a specific type) are less than the capacity reserved for that
request type. All the additional requests will be suspended until atleast one
thread is available for processing.
- We will not require extensive changes to the SolrDispatcherFilter code
thereby reducing the possibility of introducing new bugs.
- Since this new filter needs to be added to the solr webapp, folks can opt out
if they want (Please see the earlier comment from [~andyetitmoves]).
Note even for this approach, we need to implement a way to identify an internal
request (e.g. adding an extra request header/param). Now regarding the request
forwarding, I have following change in mind. Let's assume that a client C has
sent a request to node A for a collection/core hosted by node B.
- The initial request from client C will be categorized as an "external"
request.
- Node A will figure out that it does not host the requested collection/core.
It will figure out the correct Solr server (node B in this case) and send
another request to node B. Here we will ensure that this request is also
categorized as an "external" request (i.e. not to add the request header/param
even though its a server-server communication).
- Node B will process the "forwarded" request as if it were an "external"
request and return results to node A.
- Node A will return results to client C.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
