On 6/27/23 15:07, Mikhail Khludnev wrote:
It handles collection (cloud) as well. But if it's a sharded and replicated collection where the healthcheck file will be created?
In cloud mode the existing ping handler is not very reliable. You might never know which shard replica is going to actually get the ping request, and it's only core aware, not collection/shard/replica/node aware. As a result, it has the same limitations as the DIH handler does in cloud mode.
At one time I had an install that used the ping handler to tell haproxy which replicas (not using cloud OR /replication) were down either because of problems or because I wanted to explicitly take it out of rotation. It worked really well for that.
I think it's useful as-is for standalone mode, and I would hate to see it removed unless there is a plan to replace its functionality with something better. Extending it for cloud mode should involve the ability to disable health check at the collection level and the node level, with the health check file probably living in ZK, not on the disk. Disabling healthcheck would make it so SolrCloud's built-in load balancing would not use the disabled resource, as well as returning a non-200 response code from the ping handler or its replacement.
Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
