(not a bug) How to handle an intermittently down elasticsearch cluster?

[henryhsue]

I have a service that uses elasticsearch and currently panics when initializing if the elastic client cannot be initialized. I'd prefer the service to be able to start without elasticsearch, and then keep trying to initialize the client in the background.

Is this a reasonable approach? Or should I be using the Simple Client and initialize that for every request that requires elasticsearch?

I see in the documentation it says that the Simple Client doesn't have sniffing and health checks. Do I need these if I require routing through coordinating-only nodes on kubernetes? My understanding is that sniffing will find the nodes that can be connected to in the cluster, but I'm not sure if that is limited to the coordinating-only nodes if I have set up coordinating-only nodes. If that is not the case, then will I have to disable sniffing? (or just use the simple client on a request basis?)

[olivere]

Hmm... I see what you're after. The idea back then with NewClient was that the Client initializes once, at startup, and then puts itself into the background. Its responsibilities are to keep itself healthy by periodically introspecting into the cluster and updating connection states. However, you're right in that these lines make sure that you can't have a Client that is initially "unavailable".

Looking back at this, I see no reason why that can't be. You just have to be prepared for a Client to not return anything sensual—which you have to anyway.

Maybe there should be an option like SetIgnoreConnectionFailuresOnSetup(true) which is false by default, to keep the existing behaviour.

Sure, you can use NewSimpleClient on a per-request basis—YMMV. You don't need sniffing and healthchecks for "simple client" because you just typically only create it for a single (or a few) request(s): NewSimpleClient creates nothing more than a configured *http.Client.