[
https://issues.apache.org/jira/browse/SOLR-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891187#comment-17891187
]
David Smiley commented on SOLR-17158:
-------------------------------------
I sympathize with the 200 response; it's reasonable and also debatable though.
If we could supply a bit of metadata in the header for the caller to know what
percentage of sub-shards timed out, the caller might want to know to act on
this (i.e. do fallback / failing scenario actions).
I take no issue with the subShards using the full 5 seconds for this
unrealistic sleep(5000,0) call. But the coordinator need not wait on the
take() indefinitely; it should wait no more than the 10 milliseconds given. I
think it's sad if we must wait for one sub-shard request to respond; feels
needless to me; a deficiency. I suppose you might say this shouldn't even
happen because the sub-shard *should* not take more than 10ms itself. I wish
it didn't but where I work we see it can happen (via SOLR-17320). Hmmm; I'm
not sure what action to take.
> Terminate distributed processing quickly when query limit is reached
> --------------------------------------------------------------------
>
> Key: SOLR-17158
> URL: https://issues.apache.org/jira/browse/SOLR-17158
> Project: Solr
> Issue Type: Sub-task
> Components: Query Limits
> Reporter: Andrzej Bialecki
> Assignee: Gus Heck
> Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0), 9.8
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> Solr should make sure that when query limits are reached and partial results
> are not needed (and not wanted) then both the processing in shards and in the
> query coordinator should be terminated as quickly as possible, and Solr
> should minimize wasted resources spent on eg. returning data from the
> remaining shards, merging responses in the coordinator, or returning any data
> back to the user.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
