Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REST API: Replace error code 503 with 429 when appropriate #6627

Closed
spinscale opened this issue Jun 26, 2014 · 2 comments
Closed

REST API: Replace error code 503 with 429 when appropriate #6627

spinscale opened this issue Jun 26, 2014 · 2 comments

Comments

@spinscale
Copy link
Contributor

Right now Elasticsearch returns 503 on a couple of occasions, where the full cluster is actually not completely out of service, but a single node just has a problem, so that trying another node makes sense. On the other hand there are error messages, where telling the client to wait a bit makes more sense in order to reduce load (when the threadpool queue is full for example).

There is a HTTP status code for that, called 429 (Too many requests).
It can be found in RFC 6585 (Additional HTTP status codes), see https://tools.ietf.org/html/rfc6585

Closes #4066

@spinscale spinscale changed the title REST API: Replace 503 with 429 when appropriate REST API: Replace error code 503 with 429 when appropriate Jun 26, 2014
kimchy added a commit to kimchy/elasticsearch that referenced this issue Jun 26, 2014
Thread rejection should return too many requests status code, and not 503, which is used to also show that the cluster is not available
 relates to elastic#6627, but only for rejections for now
closes elastic#6629
kimchy added a commit that referenced this issue Jun 27, 2014
Thread rejection should return too many requests status code, and not 503, which is used to also show that the cluster is not available
 relates to #6627, but only for rejections for now
closes #6629
kimchy added a commit that referenced this issue Jun 27, 2014
Thread rejection should return too many requests status code, and not 503, which is used to also show that the cluster is not available
 relates to #6627, but only for rejections for now
closes #6629
@areek areek assigned rjernst and unassigned rjernst Jun 29, 2014
@kimchy
Copy link
Member

kimchy commented Jun 30, 2014

I went thought all the places that return 503, and I think we are good except for FlushNotAllowed failure, which is a transient state where flush is not allowed on a shard that is being recovered from, unsure which code we should use there. We use 503 also when there are no shards to satisfy a search request, I think its appropriate.

@spinscale
Copy link
Contributor Author

closing this for now, the too many requests error does not make sense for the flush allowed failure IMO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants