[ 
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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to