Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
None
Description
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 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.
Attachments
Issue Links
- links to
