It was an 8x but it's more hypothetical if /update were to support this. It does where I work :-)
Weird that you got status=0 and fewer results without specifying shards.tolerant=true On Sun, Mar 31, 2024 at 4:41 PM Gus Heck <gus.h...@gmail.com> wrote: > > Hmm, I took the initial statement about returning 500 at face value when I > wrote my response above, but with actual testing I'm not seeing that > behavior in any recent version... (tested 9.1, 9.4, 9.5, main) this cause a > some confusion since I am working in that code right now and having read > this I made sure in paths I added I threw 500 and then discovered that it > wasn't reliably thrown all the time when I was testing... I initially > assumed I must have broken it until I stashed everything and made this > discovery :). > > David, what version were you observing 500 status for a time limit > exceedance with timeAllowed? Is it an 8.x? I didn't test any of those... > > Searching an index of the ref guide here which I use for testing sometime > (this index is easily created via > https://github.com/nsoft/index-solr-ref-guide) in each of those versions I > got: > { > "responseHeader":{ > "zkConnected":true, > "partialResults":true, > "status":0, > "QTime":20, > "params":{ > "q":"hdfs", > "indent":"true", > "q.op":"OR", > "timeAllowed":"1", > "useParams":"", > "_":"1711914604030"}}, > > "response":{"numFound":2,"start":0,"maxScore":3.6057181,"numFoundExact":true,"docs":[ > > Or without timeAllowed: > > { > "responseHeader":{ > "zkConnected":true, > "status":0, > "QTime":66, > "params":{ > "q":"hdfs", > "indent":"true", > "q.op":"OR", > "useParams":"", > "_":"1711914604030"}}, > > "response":{"numFound":9,"start":0,"maxScore":4.5576544,"numFoundExact":true,"docs":[ > > As a side quirk, the numFoundExact seems a bit misleading... alongside > partialResults:true > > On Wed, Mar 20, 2024 at 5:59 PM Gus Heck <gus.h...@gmail.com> wrote: > > > I don't like the current 500. That's sharing the same conceptual space as > > NPE, bugs and other hard failures for which IT should be paged at 2:30 am. > > > > 5xx indicates that there is a problem with the server and that there is > > nothing the client can do, and also would typically be flagged by > > monitoring tools as a system problem. That's not true, often the query can > > be modified, or resubmitted of peak hours etc... The server is not > > compromised. > > > > 4xx indicates that "the client should correct their request" which is true > > if things are taking a long time because the request was dumb in the first > > place, but since that's entirely relative to the index and the hardware, > > it's unknowable from our perspective so it also feels wrong to send a 400, > > because it could be a perfectly fine request sent in the middle of a DOS > > attack... Not the client's fault. > > > > Stepping back a moment let's think about the request: it says "run this > > query for up to X milliseconds" ... the server did that successfully so > > really the response ought to be a success. > > > > So 206 Partial Content seems to make the most sense > > > > -Gus > > > > > > On Wed, Mar 20, 2024 at 2:06 PM Chris Hostetter <hossman_luc...@fucit.org> > > wrote: > > > >> > >> : I still think 503 is appropriate when timeAllowed is exceeded. The > >> : service requested is a reponse within the set time. That service is not > >> : available. Here are the RFC definitions of 500 and 503. Exceeding > >> : timeAllowed isn’t an “unexpected condition”, it is part of the normal > >> : operation of that limit. > >> > >> Devils avocate argument: it is an "unexpected condition" -- it's > >> unepected > >> that the request wasn't able to be processed w/in the configured limits. > >> If you > >> expected that the request could *NOT* be processed, why send it w/those > >> limits? > >> > >> I'm -0 to using 503 because it's worded to very explicitly be a temporal > >> situation: failue "due temporary overload or scheduled maintenance" -- > >> those aren't *examples* of why a server MAY return 503, those are the > >> explict circumstances indicated by a 503 -- and neither one is directly > >> applicable for a query limit being exceeded. An otherwise idle server > >> might still fail a request with a query limit configured -- regardless of > >> wther the server is "overloaded" or down for "scheduled maintenance" -- > >> and there is no reason for a client to assume retrying a request with the > >> same query limits will succeed again in the future. > >> > >> > >> Bottom line for me: I'm fine w/changing the default response code to > >> anything -- as long as we make it configure. But i *strongly* urge us > >> not to use a non-standard error code that already has very specific, well > >> established, meaning with well known proxy software. > >> > >> > >> : 6.6.1. 500 Internal Server Error > >> : > >> : The 500 (Internal Server Error) status code indicates that the server > >> : encountered an unexpected condition that prevented it from fulfilling > >> : the request. > >> : https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.1 > >> : > >> : 6.6.4 503 Service Unavailable > >> : > >> : The 503 (Service Unavailable) status code indicates that the server > >> : is currently unable to handle the request due to a temporary overload > >> : or scheduled maintenance, which will likely be alleviated after some > >> : delay. The server MAY send a Retry-After header field > >> : (Section 7.1.3) to suggest an appropriate amount of time for the > >> : client to wait before retrying the request > >> : https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.4 > >> : > >> : Solr could even return 503 with a message of “timeAllowed exceeded”. > >> : > >> : I spent about a decade working on a search engine with an integrated > >> web spider. Accurate HTTP response codes are really useful. > >> : > >> : wunder > >> : Walter Underwood > >> : wun...@wunderwood.org > >> : http://observer.wunderwood.org/ (my blog) > >> : > >> : > On Mar 19, 2024, at 3:12 PM, Chris Hostetter < > >> hossman_luc...@fucit.org> wrote: > >> : > > >> : > > >> : > Agree on all of Uwe's points below > >> : > > >> : > I think 500 is the most appropriate for exceeding QueryLimits -- > >> : > unless/until we decie we want Solr to start using custom response > >> codes in > >> : > some cases, but in that case i would suggest we explicitly *avoid* > >> using > >> : > 504, 524, & 529 precisely because they already have specific meanings > >> in > >> : > well known HTTP proxies/services that don't match what we're talking > >> about > >> : > here. > >> : > > >> : > As far as one of David's specific observations... > >> : > > >> : > : > ideal IMO because Solr's health could reasonably be judged by > >> looking > >> : > : > for 500's specifically as a sign of a general error that service > >> : > : > operators should pay attention to. > >> : > > >> : > Any client that is interpreting a '500' error as a *general* > >> indication of > >> : > a problem with Solr, and not specific to that request, would not be > >> : > respecting the spec on what '500' means. *Some* '5xx' are documented > >> : > to indicate that there may be a general problem afflicting the > >> : > server/service as a whole (notably '503') but most do not. > >> : > > >> : > But i also think that if we really want to cover our basis -- we can > >> : > always make it configurable. Let people configure Solr to return > >> : > 500, 400, 418, 666, 999, ... wtf they want ... but 500 is probably > >> the > >> : > best sane default that doesn't carry around implicit baggage. > >> : > > >> : > : 524 or 504 both refer to timeouts, but both are meant for proxies > >> (so reverse > >> : > : proxy can't reach the backend server in time). So both of them do > >> not match. > >> : > : > >> : > : 408 is "request timeout", but that's client's fault (4xx code). In > >> that case > >> : > : its a more technical code because it also requires to close the > >> connection and > >> : > : not keep it alive, so we can't trigger that from Servlet API in a > >> correct way. > >> : > : > >> : > : 503 does not fit well as Solr is not overloaded, but would be the > >> only > >> : > : alternative I see. Maybe add a new Solr-specific one? Anyways, I > >> think 500 > >> : > : seems the best response unless you find another one not > >> proxy-related. > >> : > : > >> : > : Uwe > >> : > > >> : > > >> : > -Hoss > >> : > http://www.lucidworks.com/ > >> : > > >> : > --------------------------------------------------------------------- > >> : > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> : > For additional commands, e-mail: dev-h...@solr.apache.org > >> : > > >> : > >> : > >> > >> -Hoss > >> http://www.lucidworks.com/ > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > -- > > http://www.needhamsoftware.com (work) > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
