Increased timeout as default was too short on slow machines

[80er]

On slower machine the default timeout of 30s for waiting for yellow state is not enough. If method returns to early exceptions are thrown on startup.

[lonvia]

I'm not convinced that this is a good idea. When it takes more than 30s to start up Photon, there is a good chance that queries will be slow as well. Did you investigate why startup on your machine is so slow, where the time is spent?

[fnavarrogonzalez]

Also its a random hardcoded value that match your use case but if you add some kind of timeout you should be able to parameterize it.

[80er]

I'm not convinced that this is a good idea. When it takes more than 30s to start up Photon, there is a good chance that queries will be slow as well. Did you investigate why startup on your machine is so slow, where the time is spent?

The startup was slow because my NAS is not the fastest of course and also it was currently under load. The query performance afterwards was acceptable at least for my use case. This also does not mean that the startup will be longer. It will still return after the yellow state is reached. It is just waited longer until this is done.

Also its a random hardcoded value that match your use case but if you add some kind of timeout you should be able to parameterize it.

Agreed. Magic numbers are always bad. What would be the expectation to pass it from the outside? Thinking about containerized environments using environment variables could be a choice. Would that fit to the overall configuration concept? Or is it worth doing this as elasticsearch anyway seems to be a deadend and opensearch will be used in the future.

[lonvia]

Maintaining environment variables that are never used in practice is not ideal either.

In such a rather special setup as yours, it is probably better to add some pre-warming commands before the Photon startup that ensure that your NAS is up and running.

I'll reconsider adding something to Photon, if that becomes apparent that this is a regular problem in different setups. For the moment, this is too specific. I'm sorry.

[80er]

The problem also appeared as someone tried to deploy photon in Azure Cloud. And NAS was up and running but it takes simply more than 30s for elasticsearch to start. Be it load on the disk or CPU. On my NAS I could wait until it idles but how to do that in Azure? Also the API of elasticsearch ist here suboptimal as it simply returns after 30s regardless in which state the cluster ist what leads to heisenbugs and strange exceptions on startup after the first queries and photon simply exits. Do not want to force the merge, just wanted to make sure the problem ist understood and also documented here If someone runs into the same problem.