I'm not sure it's bug or question and to which project it relates, but I've found this case trying spring cloud bus, so I decided to post here.

Problem is whenever refresh event is sent to bus all service stats to re-registering in Eureka since eureka discovery client is refresh-scoped. For test I've used: SB version: 2.1.1.RELEASE Cloud version: Greenwich.RC2 Service name: frontend-service Instance count: 2 Spring Cloud Netflix Bus refresh event kicks off all services from Eureka Spring Cloud Netflix Bus refresh event kicks off all services from Eureka

So is there any workaround for this? Since I'm looking for automatic configuration refresh, but not willing to see my cluster to be down after this.

Comment From: spencergibb

Your saying all your services reregister during refresh? Can you try again with Greenwich.RELEASE?

Comment From: tdanylchuk

yes, most likely it's because of EurekaClient is marked by annotation @RefreshScope and it deregisters instance on closing old bean of eureka client and registered itself with new bean after it's been created.

Another issue relates to broken configs, so if fetched configs are not okay from config service (@Min(10) validation for example) service goes DOWN (because health indicator of refreshScope is DOWN), and whole cluster is unreachable because of it. But service itself continues to work with non-validated property. I guess it's another issue and I'll post it after some investigation of possibility to 'dry-run' of configuration refresh is it's possible of course.

Comment From: spencergibb

Did you try again with Greenwich.RELEASE?

Comment From: tdanylchuk

yep

Comment From: ryanjbaxter

If the refresh event deregisters the client and then re-registers the client I dont understand what the issue is....I must be missing something.

Comment From: tdanylchuk

The problem that we might have several seconds with all instance to be de-registered before they get registered again. And at this point of time Ribbon could refresh it's servers lists and would fail on empty pool, since bus will refresh whole cluster at the same time.

Comment From: ryanjbaxter

What if you configured retry with some kind of backoff policy and used a circuit breaker? Hopefully things would come back up and reregister fairly quickly and if your client does not get the updated server list by that time you would hit the fallback. That would certainly mitigate the issue.

I agree there is a bit of a potential issue here, but in my opinion, the chances of this happening seems slim.

Comment From: heowc

I think it's related to this document - https://docs.spring.io/spring-cloud-netflix/docs/current/reference/html/#refreshing-eureka-clients

Isn't this the default behavior? Of course, this issue is quite old, so I'm not sure what it was like back then.