[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585227#comment-14585227
]
Hrishikesh Gadre commented on SOLR-7344:
----------------------------------------
>>Ouch... I hope that's not true. That would certainly be very invasive to
>>clients. Hopefully there's blocking behavior in there too, and requests are
>>only rejected after too many of them are buffered?
The current implementation is as follows,
- Whenever a request can not processed immediately, it is suspended and placed
on an internal queue.
- We associate a (configurable) timeout value with this request and attach a
callback (using Servlet 3 AsyncListener).
- Whenever the timeout occurs, we attempt to reschedule request. If a thread is
available for the corresponding request type, then the request goes through.
Otherwise we send the HTTP 503 error.
So from client perspective it is still blocking (until a timeout happens on the
server). At this point either it will get a valid response or an HTTP 503
error. Please take a look
[here|https://github.com/hgadre/servletrequest-scheduler/blob/master/src/main/java/org/apache/solr/scheduling/RequestSchedulerFilter.java#L138]
for more details.
> Allow Jetty thread pool limits while still avoiding distributed deadlock.
> -------------------------------------------------------------------------
>
> 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
