[
https://issues.apache.org/jira/browse/SOLR-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816633#comment-17816633
]
ASF subversion and git services commented on SOLR-17140:
--------------------------------------------------------
Commit 07f65499723d3190041849a7b3e2d70593b3eda5 in solr's branch
refs/heads/main from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=07f65499723 ]
SOLR-17140 - provide extensible query limit concept. (#2237)
* SOLR-17140 - provide extensible query limit concept.
This replaces SolrQueryTimeoutImpl.java with a much simpler SolrTimeLimit and
provides a QueryLimits class to allow addition of additional types of limits.
(see also SOLR-17138)
* SOLR-17140 ensure we always have limits. SolrRequestInfo is created by
HttpSolrCall, so any code path not flowing through that needs to ensure
SolrRequestInfo if it wants to use limit functionality.
* SOLR-17140 Limits should not be lost if we push a new request onto the stack.
This makes it difficult to change limits for sub-requests, but I'm not
convinced that such a thing makes sense anyway.
> Refactor SolrQueryTimeoutImpl to support other implementations
> --------------------------------------------------------------
>
> Key: SOLR-17140
> URL: https://issues.apache.org/jira/browse/SOLR-17140
> Project: Solr
> Issue Type: Sub-task
> Reporter: Andrzej Bialecki
> Assignee: Gus Heck
> Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The current way we model time limits for timeAllowed involves a lot of static
> methods and thread locals in a class called SolrQueryTimeoutImpl. As it is it
> is, this class makes it almost impossible to add an alternate implementation
> based on something other than wallclock time. This ticket aims to simplify
> the code and make it more extensible at the same time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
