[
https://issues.apache.org/jira/browse/SOLR-17926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-17926:
------------------------------------
Description:
Spin-off from SOLR-17869.
Currently only {{TopGroupsShardRequestFactory}} subtracts the time already
spent on local request processing from {{timeAllowed}} before sending shard
requests.
This is inconsistent and likely not optimal. Since {{timeAllowed}} tracks
wall-clock time it makes sense to track the same starting point for all phases
of distributed request processing and terminate processing early when the
allowed time runs out, as compared to the original starting point.
This is not the way it works now, though (except for this special case of
grouping queries): the same time span is allocated to the query coordinator and
to the shard requests where the processing starts later, which means that the
coordinator may time out while waiting for responses even if all shard requests
succeeded.
[~dsmiley] suggested to use {{SolrRequestInfo.getNOW()}} instead, as the
absolute starting point for both local and distributed requests, and compare
{{timeAllowed}} to that starting point. However, this relies on correct time
sync between nodes.
was:
Spin-off from SOLR-17869.
Currently only {{TopGroupsShardRequestFactory}} subtracts the time already
spent on local request processing from {{timeAllowed}} before sending shard
requests.
This is inconsistent and likely not optimal. Since {{timeAllowed}} tracks
wall-clock time it makes sense to track the same starting point for all phases
of distributed request processing and terminate processing early when the
allowed time runs out, as compared to the original starting point.
This is not the way it works now, though (except for this special case of
grouping queries): the same time span is allocated to the query coordinator and
to the shard requests where the processing starts later, which means that the
coordinator may time out while waiting for responses even if all shard requests
succeeded.
[~dsmiley] suggested to use {{SolrRequestInfo.getNOW()}} instead, as the
absolute starting point for both local and distributed requests, and compare
{{timeAllowed}} to that starting point.
> Discount timeAllowed for all types of queries
> ---------------------------------------------
>
> Key: SOLR-17926
> URL: https://issues.apache.org/jira/browse/SOLR-17926
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 9.9
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
>
> Spin-off from SOLR-17869.
> Currently only {{TopGroupsShardRequestFactory}} subtracts the time already
> spent on local request processing from {{timeAllowed}} before sending shard
> requests.
> This is inconsistent and likely not optimal. Since {{timeAllowed}} tracks
> wall-clock time it makes sense to track the same starting point for all
> phases of distributed request processing and terminate processing early when
> the allowed time runs out, as compared to the original starting point.
> This is not the way it works now, though (except for this special case of
> grouping queries): the same time span is allocated to the query coordinator
> and to the shard requests where the processing starts later, which means that
> the coordinator may time out while waiting for responses even if all shard
> requests succeeded.
> [~dsmiley] suggested to use {{SolrRequestInfo.getNOW()}} instead, as the
> absolute starting point for both local and distributed requests, and compare
> {{timeAllowed}} to that starting point. However, this relies on correct time
> sync between nodes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
