[
https://issues.apache.org/jira/browse/SOLR-17333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Gibney resolved SOLR-17333.
-----------------------------------
Fix Version/s: 9.7
Resolution: Fixed
> Various rate limiting fixes
> ---------------------------
>
> Key: SOLR-17333
> URL: https://issues.apache.org/jira/browse/SOLR-17333
> Project: Solr
> Issue Type: Bug
> Reporter: Michael Gibney
> Assignee: Michael Gibney
> Priority: Minor
> Fix For: 9.7
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Solr rate limiting (introduced with SOLR-13528) has a number of issues with
> its current implementation:
> # live-update via clusterprops is incomplete, and does not work. Some
> settings can be updated, but for others -- namely, the actual request limits
> -- attempted changes are silently ignored. (aside from the fact that it
> doesn't work, the high-level approach to config changes is not ideal,
> mutating objects in potentially brittle ways)
> # there is a bug in slot borrowing that can in principle cause slots to be
> denied to native request types with guaranteed slots, even when plenty of
> slots are available. More likely consequences of the bug would be: native
> request types waiting up to twice as long as specified by {{slot allocation
> millis}} before failing to acquire, or pointlessly waiting {{slot allocation
> millis}} even when plenty of slots are available
> # unnecessary state-tracking of existing requests; we should instead close
> out rate-limiting slots via try-with-resources. This will be safer, cleaner,
> more efficient, and support more flexible slot-granting. (currently the
> outstanding state is tracked in a separate map in the {{RateLimitManager}},
> which is needlessly complex/inflexible)
> # refguide documentation is incomplete. Most importantly: ratelimiting won't
> work at all without the addition of a `Solr-Request-Type` header, but [as of
> current version
> v.9.6|https://solr.apache.org/guide/solr/9_6/deployment-guide/rate-limiters.html]
> the refguide documentation doesn't mention the required header, so any user
> would be thoroughly confused!
> I've bundled these issues together for simplicity; I can break them apart if
> folks prefer, but the changes are kind of intertwined, and really IMO
> together constitute a single high-level follow-up to the introduction of rate
> limiting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
