[automatic failover] HealthCheckImpl improvements - use shared executors across all health checks

[ggivo]

Currently, each HealthCheck instance uses its own ScheduledExecutorService for scheduling (via scheduleAtFixedRate) and a separate executor (Executors.newCachedThreadPool()) for running the actual health check tasks.

That works but we might save some resources by sharing the scheduler among all HealthChecks

Enhancement idea:
Consider introducing a shared scheduler and/or executor service across all HealthCheck instances:

• Single shared ScheduledExecutorService: schedule health checks for all endpoints, reducing thread footprint.
• Shared worker executor pool: power the health check logic from a common pool, avoiding too many cached pools.

[SwapnaliY16]

Hi @ggivo, I’d like to work on this enhancement.

My plan is to refactor HealthCheckImpl so that instead of each instance creating its own ScheduledExecutorService and ExecutorService, they will use shared, static executors.

Specifically:

• Introduce a single shared ScheduledExecutorService for scheduling all health checks.

• Optionally, introduce a shared worker pool for running health check logic, instead of creating a new cached pool per instance.

This should reduce thread creation overhead and improve resource usage while keeping the current behavior intact.

Please let me know if this approach aligns with what you had in mind before I proceed.

[ggivo]

@SwapnaliY16
Hey, thanks for the note, and we will be glad to get some help.

We are trying to wrap up a beta version of the automatic failover feature, and planning to do some refactoring/renaming, which might lead to conflicts. Planning to wrap up the beta this/next week, and I will suggest waiting a bit with this task. Till we get the beta out.

Let's also see what @atakavci thinks, he is driving most of the effort here.

[SwapnaliY16]

Thanks @ggivo for the update. That makes sense. I’ll hold off on this task until the beta version of the automatic failover feature is wrapped up, to avoid conflicts.

I’ll keep an eye on the issue and jump in once things are more stable. Meanwhile, I can explore other open issues or improvements in the project.

Looking forward to @atakavci’s thoughts as well.