This does reuse QueryTimeout infra and already existing collectors, it just extends / refactors it to allow other criteria than wall-time clock.
> On 6 Feb 2024, at 23:01, David Smiley <dsmi...@apache.org> wrote: > > I will look at this! > > - Ticket for my refactoring > https://issues.apache.org/jira/browse/SOLR-1714 > > 1714, ehh? :-) > > Another thought I had that I want to share is that I think the query > tracking and cancellation could use the same QueryTimeout > infrastructure. I don't like that it adds its own stuff (e.g. yet > another Collector) that looks just like it. > > On Tue, Feb 6, 2024 at 10:08 AM Gus Heck <gus.h...@gmail.com> wrote: >> >> To save folks some clicking around, and to provide a little more detail, >> here are a few links. >> >> - The first step was to refactor/replace QueryTimeoutImpl: PR >> https://github.com/apache/solr/pull/2237. >> - Building on that will be Andrzej's PR >> >> https://github.com/apache/solr/pull/2244/commits/7984fba7c6fb99853c89e69c093584487a5201de >> - The Parent ticket is https://issues.apache.org/jira/browse/SOLR-17138 >> - Ticket for my refactoring >> https://issues.apache.org/jira/browse/SOLR-1714 >> - Ticket for the new CPU limit implementation by Andrzej >> https://issues.apache.org/jira/browse/SOLR-17141 >> >> It would be nice to have additional eyes on the refactor, including removal >> of SolrTimeoutImpl, and use/changes to SolrRequestInfo. >> >> The current PR's pass all tests, and are nearing readiness for merging. >> >> -Gus >> >> >> >> On Tue, Feb 6, 2024 at 9:31 AM rajani m <rajinima...@gmail.com> wrote: >> >>> I have updated the jira with my vote and totally agree that solr lacks this >>> way to limit the usage and a single query bringing all the nodes in the >>> cluster down. I'd love to review/contribute to PR . >>> >>> Thank you for bringing up this issue Andrzej. >>> >>> >>> >>> On Mon, Feb 5, 2024 at 4:16 PM Andrzej Białecki <a...@getopt.org> wrote: >>> >>>> Hi all, >>>> >>>> I’d like to draw your attention to SOLR-17138. Jira description gives a >>>> more detailed background of the issue - but in short, Solr lacks a robust >>>> way to limit the resource usage (be it CPU time or memory consumption or >>>> other resource) on a per-query basis. CircuitBreakers help to an extend >>> but >>>> they are a global measure. This work focuses on monitoring and >>> terminating >>>> individual queries that exceed configured limits. >>>> >>>> Reviews / comments / suggestions are highly appreciated! >>>> >>>> — >>>> >>>> Andrzej Białecki >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org