Closed AaronRustad closed 8 years ago
I have a similar setup (much lower volume though), and running into the same problem.
Might be related to #220. I don't have a dedicated master node in AWS, so the 503s might simply be 2 nodes disagreeing. Whatever the cause is, and I suspect it's something internal to Amazon, I've added the retry_on_status: [502,503,504]
to my client config and the errors have disappeared.
It's only been an hour since I added that setting, so I don't know if this is The Fix™.
It doesn't pinpoint the problem, but knowing that AWS rarely explains any underlying problems, it might be a wise thing to do the same.
Thanks.
@AaronRustad, unfortunately, it doesn't ring any bells... As @MetricMike suggests, are you using connection reloading ("sniffing")? The AWS setup might trip ut the process, but I haven't investigated it in a real environment.
Hi @AaronRustad, any news? :)
Hi! I did use @MetricMike's retry_on_status
and we're not seeing the errors. To be fair, we might still be getting them, but now they're hidden by the retry. However, it seems to be a decent solution and I don't have any evidence that it is a multi-client issue.
I see. The errors should stil be in the logs, so if it looks like a problem, ping me again please!
I just had this error happen on a client's production server. Any insight as to what might have caused this?
I just saw this today in our production environment. US-EAST-1
The Elasticsearch clients go through rigorous testing and validation against the official Elasticsearch distribution coming from Elastic. Since the AWS Elasticsearch Service has incompatible APIs with Elasticsearch itself, either by missing APIs or has incompatible format, we do not support it. Please consider using Elastic Cloud for an official and formally supported hosted Elasticsearch distribution.
Yeah this is the conclusion I came to as well.
Not to mention the fact that amazon elasticsearch support is horrible.
There’s no reason to use it whatsoever.
On Wed, Jun 10, 2020 at 6:34 PM Fernando Briano notifications@github.com wrote:
The Elasticsearch clients go through rigorous testing and validation against the official Elasticsearch distribution coming from Elastic. Since the AWS Elasticsearch Service has incompatible APIs with Elasticsearch itself, either by missing APIs or has incompatible format, we do not support it. Please consider using Elastic Cloud https://cloud.elastic.co/ for an official and formally supported hosted Elasticsearch distribution.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/elastic/elasticsearch-ruby/issues/294#issuecomment-642302588, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACEK54ZY3B5MGOMAT223RLRWAC7BANCNFSM4B677JZQ .
We're using AWS Elasticsearch service and we're currently seeing a number of the following errors:
Elasticsearch::Transport::Transport::Errors::ServiceUnavailable: [503] {"Message":"Call to Authorization engine failed"}
The number of requests to ES is usually around 3000/day, and we've been seeing a couple every one or two days (today we saw 10). We issuing these requests from a Rails application and the following code is how we initialize the client.
Of particular interest is the fact that we use two Elasticsearch clients (two AWS ES clusters). I'm not sure if that could be contributing to the issue. If the signing of requests tied to the service endpoint perhaps, perhaps two clients will result in the occasional poorly worded error?
Stack trace follows:
All ideas welcomed! Aaron.