How to make config client pull config changes via RefreshEndpoint

[jmnarloch]

I'm trying to figure out a way to automate the refresh of configuration on client side. This has been already addressed here: #138 giving a good example on how to implement a "pull" like refresh, although I'm not sure whether constantly hammering the config server it's the best possible solution.

Config server is already pretty capable of detecting changes, so I have simple proposition to add an event to config server a form of SPI that could be easly consumed in the embeeded mode and based on which it would be easy to implement extensions and own logic: jmnarloch@c1a0035#diff-14f7a9bbd398562fdfd12ce9f6619d7cR179 - this is not yet "workable solution", merely a proposition.

[dsyer]

The proposed change is pretty small, so likely to just get merged if you send a pull request, but it also has a pretty small impact on its own. You say the config server is capable of detecting changes, but I don't see how exactly. For sure it knows how to construct new property sources, but how would it know when to do that, or when a change had been made, or if there was a change which clients were interested in it? This is an important topic, so it's worthwhile to have a discussion about all that as well.

[jmnarloch]

Yes I guest that I misunderstood the functionality of loading the config on demand from the client directly. Although correct me if I am wrong, but I am thinking it might be possible to call POST "/refresh" on the config server in order to trigger the reload of properties and afterwards use the event I had mentioned to propagate this information farther.

[jmnarloch]

There is one fallowup to #138 and calling RefreshEndpoint.refresh() method. I had created a gist: https://gist.github.com/jmnarloch/7be51b6d00b49de84cfa

It turns out this does not entirely work with Eureka setup. What I mean is whenever the refresh method is being called, first of all it result is deregistration of the endpoint from Eureka and for some reason this is permament, the service does not re-register in Eureka again. The logs might be helpfull here:

https://gist.github.com/jmnarloch/fc1aa7fa303cb983e6c0

It looks like the order of the operations is not entirely correct, the order is as fallows:
Registering application rest-service with eureka with status UP
Unregistering application rest-service with eureka with status DOWN

[jmnarloch]

I had build small extension that will help to setup scheduled refresh and "Pull" the configuration from configured server, if you would like to I could turn this into a pull request: https://github.com/jmnarloch/spring-cloud-config-refresh

Either way I would like to work on enabling the "Push" like feature through the Config server.

[dsyer]

The push notifications are already discussed in #86. Please feel free to contribute there.

[dsyer]

There's a bit of a mixed discussion here, so I tried to point you at some other links to follow up on the push changes. Your issue with eureka registrations being lost appears to be the only thing left. It can't reproduce it so I suspect a pilot error. Can you post a minimal sample project to reproduce please?

[jmnarloch]

Cool thanks,

I had setup a project: https://github.com/jmnarloch/spring-boot-microservices-sandbox/tree/eureka-refresh-deregister that I am always able to see this issue. You will have to build it and run minimum three services: EurekaApplication, ConfigApplication, RestApplication. After that the last one will listen on port 8541. After waiting for it to register in Eureka simply do:

curl -d {} http://localhost:8541/refresh

What will happen is that DefaultLifecycleProcessor will caused the fallowing methods to execute

• EurekaDiscoveryClientConfiguration#start
• EurekaDiscoveryClientConfiguration#stop
• EurekaDiscoveryClientConfiguration#close - is being eventually called

Verified with cloud-starter-config and cloud-starter-eureka 1.0.3.RELEASE

What really should happen is the logic that DiscoveryClientConfigServiceAutoConfiguration#init method enforces and the order of method calls, at least I think so.

[dsyer]

I can't build your sample:

...
FAILURE: Build failed with an exception.

* Where:
Script '/home/dsyer/dev/cloud/workspace/jmnarloch/gradle/release.gradle' line: 15

* What went wrong:
A problem occurred evaluating script.
> No such property: ossrhUsername for class: org.gradle.api.publication.maven.internal.deployer.DefaultGroovyMavenDeployer
...

Maybe something simpler would work?

[jmnarloch]

Sorry for that I had fixed the build and double check that it is going to work without any extra configuration/properties.

[dsyer]

I think this is probably covered now by 8d8e07a