Introduce strategy for running HealthIndicators

[vpavic]

This PR introduces strategy for running HealthIndicator instances.

The default implementations keep the current invocation pattern, which is sequential, and allows parallel invocation to be configured via properties. This addresses scenarios with many HealthIndicators and/or resource demanding HealthIndicator instances (see #2652).

I'll add the documentation updates later, if this enhancement is accepted.

I've signed the CLA.

[vpavic]

I've reworked/simplified PR to have minimal impact and preserve backwards compatibility which was broken for some components (namely CompositeHealthIndicator and HealthEndpoint) in the initial version.

This should be a better starting point for an enhancement request.

[shakuzen]

May want to explicitly document here that this should be greater than one if set.

[philwebb]

Thanks for the PR! We've seen the need in a few places in Boot to run things in the background and we're discussing the idea of adding a general TaskExecutor. We're going to try and address that before supporting parallel HealthIndicator invocation since it will likely have an impact.

[vpavic]

Would applying the approach described in #5619 (comment) help in speeding up the process of adding this feature?

If the user has defined an AsyncTaskExecutor that is primary, maybe we should automatically enable that feature.

[vpavic]

I've simplified the PR even more so it does not introduce any new configuration properties. Parallel invocation of health indicators is now enabled by simply registering HealthIndicatorRunner @Bean. Implementation based on AsyncTaskExecutor is provided in AsynchronousHealthIndicatorRunner.

This makes the PR not dependent of #5082.

[philwebb]

We're going to need to rework actuator support in 2.0 for reactive programming. I'll put this on hold until that work has been completed.

[snicoll]

@vpavic the registry is now merged and the reactor health indicator already uses Project reactor to dispatch the processing of health indicators if necessary. I think it would be quite interesting to have something for the servlet use case but I am not sure where to put it exactly.

As you've submitted this PR, I'd love to get your feedback on this.

[snicoll]

Spring Boot 2.1 has now an applicationTaskExecutor so perhaps we could rework this proposal based on that?

[snicoll]

This PR is quite old and would need a significant rewrite considering that we have a TaskExecutor infrastructure now. I am going to close this one as the original issue is still open.

@vpavic thanks for the PR, in any case!

[vpavic]

@snicoll Can you clarify in which direction exactly did you want to see it rewritten? Having async execution as default?

[snicoll]

I don't know yet but using applicationTaskExecutor for async execution is something I'd do.