hiteshk25 commented on PR #2493: URL: https://github.com/apache/solr/pull/2493#issuecomment-2310458755
> Now that I have had my head back into 17158 for a bit, I can better articulate some differences with this PR. This PR presumes that if we hit a failure we just want to quit as soon as possible. There are certainly use cases where partial results are not useful and loosing some of them is not a worry, but this is not always true. Imagine if you are serving products to be displayed for sale. You may want to collect as many as possible, because an error may cause the user to bounce of the site, and the less results shown, the less likely a sale. This type of use case is the what the code currently supports so in 17158 I tried to retain that default behavior and if the user specifies that they don't care about partial results I try to pick up additional gains by not returning any partials at all (less data over the wire). > > So 17158 essentially provides a least effort mode as an alternative to the default best effort mode. This is also part of why it is longer. I'm working on a slimmed down version of the prior PR eliminating a few simple refactors and touch ups that crept in added to the complexity/file count. The old PR can't continue because it predates the move to CompletableFuture. Thanks @gus-asf. I guess this time out case falls into `shards.tolerant=true`, if that returns partial response then application should be fine with that? Let me look PR 17158 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
