These are chat archives for spring-cloud/spring-cloud

27th
Jan 2015
Ken
@schultzy51
Jan 27 2015 19:27
are there any conventions or future features for a eureka client fast fail? similar to the cloud config fast fail
Dave Syer
@dsyer
Jan 27 2015 19:47
Maybe a circuit breaker?
Ken
@schultzy51
Jan 27 2015 19:48
as in hystrix with a default response?
Dave Syer
@dsyer
Jan 27 2015 19:48
Depends what you mean by "fast fail". I certainly wouldn't want to prevent an app from starting if it couldn't find eureka.
Ken
@schultzy51
Jan 27 2015 19:48
we’re debating that exact thing…what’s your reasoning for that?
Dave Syer
@dsyer
Jan 27 2015 19:48
Yes. Hystrix is the canonical circuit breaker for eureka clients.
It's not very robust to fail an app on startup. It's extremely fragile.
Ken
@schultzy51
Jan 27 2015 19:50
since eureka can play a part in the health check of a spring boot with accuator i thought that would be good enough…but some others think the application should fail on startup if none of the eureka instances can be contacted
Dave Syer
@dsyer
Jan 27 2015 19:50
We only do it optionally for config client because it's part of the bootstrap process.
Ken
@schultzy51
Jan 27 2015 19:51
Personally I would rather see a bad health check rather than a 404
Dave Syer
@dsyer
Jan 27 2015 19:51
Eureka is more of a lifetime service (as opposed to bootstrap). You need it all the time, so you'd better be ready for it not to be there.
Health checks are nuanced. It's a business decision really - hard to automate. We have to try and provide a framework to inspect health related data.
Ken
@schultzy51
Jan 27 2015 19:54
I might have had that reversed with the health check. Eureka would contain the application health check not base the health check based on Eureka registration.
Although for certain situations I could see the benefit of having both
But yeah, you’re correct in that being a business decision.