@AmberHuang05 if you'd like us to look further, please provide a project on github or zipped up, not a partial project in badly formatted comments.

https://github.com/AmberHuang05/config-setting
have 3 zip files. Are they enough? Also I set up a local rabbitmq server, all default installation and setting
step1: start the rabbitmq server
step2: start the discovery-server
step3: start the config-server
step4: start the config-client
step5: check the http://localhost:1111, eureka monitor page, we can see both config-server and config-client instances were registered.
step6: send a POST request to config-server instance, like curl -X POST http://localhost:7001/bus/refresh
step7: go back to http://localhost:1111 page, see both config-server and config client instances were deregistered permanently from eureka server.

My guess is this is some kind of weird timing issue. If I start setting breakpoints and debugging through the code, I will notice the server will successfully reregister with the server. However without the breakpoint the reregistration does not happen correctly.

The problem appears to be that during the refresh event the CloudDiscoveryClient is destroyed and the shutdown method in Eureka client is called. This unregisters the client from Eureka but since the EurekaClient bean is used anywhere after the refresh event the EurekaClient bean is not recreated so we do not reregister the client. We need to force the EurekaClient to be recreated in order to make sure the client is reregistered.

I just uploaded a new zip file cloud-discovery-config.zip in https://github.com/AmberHuang05/config-setting
This sample did not use rabbitmq or message bus. It only contains Eureka server, config server and config client. Both config-server and config-client registered to Eureka server. After we send out a refresh post message to config client instance, the config-client instance was deregistered to Eureka server permanently.
But in this case, config server still registered with Eureka( it is one eureka client though ;-))

Waiting for fix

There's currently no timeline for Dalston.SR1

got the same issue, waiting for the fix

Waiting for fix

Should be this week (if not, next).

Waiting for fix

Waiting for fix too. Any update or release date?

Netflix 1.3.1 was released yesterday. The next Dalston release containing Netflix 1.3.1 will be released shortly.

@ryanjbaxter Thanks for the info

@ryanjbaxter Thanks, it's fixed.

yes! Thanks all, it's fixed, i used recent pom.

         <dependency>  
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Dalston.SR1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

I'm still use Dalston.Release version. How to fix it in my project?

Then you won't get the fix

@spencergibb
You are right, I'll try to upgrade version to SR4.

Hi.I am using the version Edgware.RELEASE.When I call the endpoint bus/refresh,the issue happened.Could someone plz tell me how to walk around this?

If you think there is a bug, please open another issue