Spring Cloud Config Configuration inconsistency

If a hot update is performed, there are multiple classes that need configuration changes. During the change process, some classes have been changed and some classes have not been changed temporarily, that is, the configuration of each class is not in the same version and there is inconsistency. At this time, there may be errors in the provision of external services. Is there any way to avoid this problem?

Comment From: spencergibb

It depends on how you are using properties and what mechanism you are using to refresh. Can you describe your setup in more detail, including versions and configuration?

Comment From: Parallelline1996

The hot update mechanism provides two mechanisms: Re-bind and clearing the cache. For the Re-bind mechanism, by looking up the code, the re-bind operations of multiple classes annotated with @configuarionproperties are performed in turn, non atomic operations. For the @refreshscope annotated class, the bottom layer uses the clear method of ConcurrentHashMap, which is weak consistency. Neither mechanism can guarantee the same version of each configuration during the update.

Maybe my expression in the same version is not well understood. Let me give an example: Suppose I have two configuration classes now：

@RefreshScope
@Component
public class RefreshScopeTest1 {
    @Value("${refreshScope1}")
    String scope;
}

@RefreshScope
@Component
public class RefreshScopeTest2 {
    @Value("${refreshScope2}")
    String scope;
}

In other classes, I use the two configuration classes:

    @RequestMapping("/test")
    public void test() {
        logger.info("test1={},test2={}", test1.getScope(), test2.getScope();
    }

On the current SVN, the data of the two configuration items are: refreshScope1=2 refreshScope2=2 Now I need to make changes to the configuration, such as changing two values to refreshScope1=3 refreshScope2=3 At this time, by creating the client to poll the above test method, you can get an intermediate state with a value of 2 and a value of 3.

The above is just an example, but it can be found from the simple test that the configuration update is non atomic, and there is an intermediate state, that is, some configurations have been updated, some configurations have not been updated, and the service provided may be abnormal at this time. This feels unacceptable in production.

But we couldn't think of a better plan to avoid this problem, so we asked.

Comment From: spencergibb

There are events you could use instead of refresh scope

Comment From: Parallelline1996

I 'm sorry, but I don' t quite understand. Can you be more specific or give an example?

Comment From: spencergibb

An EnvironmentChangeEvent is published in spring when refresh is called

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: Parallelline1996

Thanks for answers