I don't know whether others would find such a feature useful as one should really make sure config server is highly available. However, when I suggested that we use this awesome open source tech for centralizing our properties, I was asked to provide a failsafe feature on the client-side. Basically, if enable and path set, the client will create and update a failsafe properties file that contains all properties acquired from the config server last. If cannot connect, it will use the failsafe config.

Of course, this would open a discussion about should failsafe happen what kind of notification should take place. In our case, the requirement is simply to log a warning that this took place. A technique like this may already be doable with client as is and I just don't see it?

Comment From: dsyer

Why would the config server not be available? If it isn't wouldn't it be coming back again soon (so the existing retry behaviour should work fine)?

Comment From: satar

I would agree that it would Dave but after debating with the team here I do see some utility in such a feature as it allows for testing without config server up yet keeping it up to date from the last time it ran. I would argue that we want to be sure config server simply always available but it became a hard requirement placed on me if I want to use this, and I will repeat, awesome piece of software.

So I am wondering if maybe instead of implementing such a feature, if once the client is finished acquiring properties from the config server, it could fire an event that one could hook into? I came up with a less than ideal solution to accomplish what was requested by creating an InitializingBean and defining logic in the afterPropertiesSet() method to check for properties by calling the configServicePropertySourceLocator() and for /refresh, I have a listener for the RefreshScopeRefreshedEvent. It would be very cool if there were an event that one could listen for instead of the kludgy and admittedly problematic InitializingBean approach.

Comment From: spencergibb

I like the idea of an event.

Comment From: HagarJNode

I wonder if what I see, is somehow connected to this issue... having a MessageListener on a sqs queue seems to trigger a fetch each time new events is incoming...

@SqsListener(value = "${queue.name}")

Seems to result in 

2016-06-17 13:34:07.055  INFO 29217 --- [nio-5000-exec-1] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:08.282  INFO 29217 --- [nio-5000-exec-1] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c
2016-06-17 13:34:08.521  INFO 29217 --- [nio-5000-exec-3] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:09.391  INFO 29217 --- [nio-5000-exec-3] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c
2016-06-17 13:34:16.525  INFO 29217 --- [nio-5000-exec-5] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at: https://xxxx
2016-06-17 13:34:17.663  INFO 29217 --- [nio-5000-exec-5] c.c.c.ConfigServicePropertySourceLocator : Located environment: name=application, profiles=[main], label=master, version=4a67c66caee11fdf2e53bfa28d16eb7b1c4a622c

Guess I have to create a way around this, as we will see some heavy load on the queues we use...

Comment From: dsyer

The SQS thing seems unrelated to this issue. Please open a new ticket (maybe in spring-cloud-aws?).

Comment From: HagarJNode

... I just guessed that looking up the ${queue.name} in the value injection trigger a property look up which make the cloud config client fetch again. The queue names comes from cloud config.

Comment From: dsyer

Please just open another issue. It's nothing to do with the config client if aws is trying to reload it at the wrong time.

Comment From: liran2000

Why would the config server not be available? If it isn't wouldn't it be coming back again soon (so the existing retry behaviour should work fine)?

Problem is for configuration needed and fetched on services startup only. The scenario is that config server is temporary down at the time that some service is starting.

Problem example

property X value: - config server: B - application file: A

Config server not available for a few minutes -> service trying to load property X -> fallback to default value from application file -> A -> unexpected value :x:

Solution example

Config server not available for a few minutes -> service trying to load property X -> fallback to last value from cache -> B -> expected value :white_check_mark: