You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
running on spring-boot 1.3.3, we experienced a hanging GET /health when one dependency was down, e. g. a Mongo client running into a 10s timeout (because the MongoDB server was down).
The expected /health result would have been an immediate DOWN or UNKNOWN, but instead the page did not load for 10s.
We thought that if health checks are based on non-interruptible synchronous I/O, they'd be better executed periodically in the background with the most recent results cached with some TTL.
The idea would be to mark HealthIndicator implementations somehow (annotation, marker interface...) and have the framework handle the scheduling and caching. Cache ttl and schedule frequency (where schedule frequency should be less than the ttl otherwise the cache may be empty which would have to be reported as UNKNOWN) could be made configurable per check or globally.
It would also be cool if the built-in (autoconfigured) HealthIndicators could be configured to be async.
Is any such feature on the road map or does anyone have other ideas on solving that problem generically?
Cheers
Martin
The text was updated successfully, but these errors were encountered:
mgerlach
changed the title
Enhancement: Asynchronous Scheduled Health Checks
Enhancement: Asynchronous Scheduled Health Indicators
May 10, 2016
Hi,
running on spring-boot 1.3.3, we experienced a hanging GET /health when one dependency was down, e. g. a Mongo client running into a 10s timeout (because the MongoDB server was down).
The expected /health result would have been an immediate DOWN or UNKNOWN, but instead the page did not load for 10s.
We thought that if health checks are based on non-interruptible synchronous I/O, they'd be better executed periodically in the background with the most recent results cached with some TTL.
The idea would be to mark HealthIndicator implementations somehow (annotation, marker interface...) and have the framework handle the scheduling and caching. Cache ttl and schedule frequency (where schedule frequency should be less than the ttl otherwise the cache may be empty which would have to be reported as UNKNOWN) could be made configurable per check or globally.
It would also be cool if the built-in (autoconfigured) HealthIndicators could be configured to be async.
Is any such feature on the road map or does anyone have other ideas on solving that problem generically?
Cheers
Martin
The text was updated successfully, but these errors were encountered: