[
https://issues.apache.org/jira/browse/SOLR-13528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166137#comment-17166137
]
Varun Thacker commented on SOLR-13528:
--------------------------------------
At Slack, we ran into this scenario a few times last year - A node in the
cluster would go bad ( maybe a faulty disk ) . This node would end up queuing
tens of thousands of outstanding requests because Jetty would keep accepting
requests. This then caused issues in our proxy layer ( which is written in Java
and uses SolrJ ) by eating up all the threads .
Why I mention this is I read this comment in the code - "If available, acquire
slot and proceed -- else asynchronously queue the request." - So maybe having
an upper bound to the wait queue could be useful? Or is
`queryRequestExpirationTimeInMS` for that?
We wrote a super simple SearchHandler to implement this. This might not be
applicable in a general sense since we were in control of the backend and the
solr cluster which helped us simplify out design.
the backend would pass a "max_searches_per_node" that would get dynamically set
based on the collection / cluster we were running.
the search handler would check if it's a top level request and if that nodes
concurrent searches is above the threashold or not. If the request is over the
limit we would throw a SolrException and the backend could take appropriate
steps
Two things that we learnt while developing this was
* If you throw an exception for rate limit , make sure that error code isn't
retried by SolrJ
* Preferring a SearchHandler over a QueryComponent - If you write a
QueryComponent it's impossible to decrement the counter if the request fails in
say the HighlightComponent
> Rate limiting in Solr
> ---------------------
>
> Key: SOLR-13528
> URL: https://issues.apache.org/jira/browse/SOLR-13528
> Project: Solr
> Issue Type: New Feature
> Reporter: Anshum Gupta
> Assignee: Atri Sharma
> Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In relation to SOLR-13527, Solr also needs a way to throttle update and
> search requests based on usage metrics. This is the umbrella JIRA for both
> update and search rate limiting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
