[Bug] The uuid was not reset, which caused the dynamic configuration to not be updated

[xzyJavaX]

Search before asking

• I had searched in the issues and found no similar issues.

Apache SkyWalking Component

Java Agent (apache/skywalking-java)

What happened

When registering AgentConfigChangeWatcher in dynamic configuration, there may be different AgentConfigChangeWatchers using the same propertyKey. Although there are currently no such cases in skywalking-java, but this situation should have been taken into consideration in the previous design. For example:

private final Map<String, List<WatcherHolder>> register = new HashMap<>();

The same key can correspond to multiple WatcherHolders .
There is a logic in org.apache.skywalking.apm.agent.core.conf.dynamic.ConfigurationDiscoveryService#getAgentDynamicConfig():

// Some plugin will register watcher later.
final int size = register.keys().size();
if (lastRegisterWatcherSize != size) {
       // reset uuid, avoid the same uuid causing the configuration not to be updated.
       uuid = null;
       lastRegisterWatcherSize = size;
}

The situation where the number of keys remains unchanged, but the number of WatcherHolders corresponding to keys increases, was not considered here. If some plugins will register watchers later, but the keys they use are the same as those in the previous register, then the uuid will not be reset and these configurations will not be updated.

What you expected to happen

No response

How to reproduce

No response

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[wu-sheng]

When registering AgentConfigChangeWatcher in dynamic configuration, there may be different AgentConfigChangeWatchers using the same propertyKey

Do you mean a watcher listening two keys with values? Why?

[xzyJavaX]

No, it's two watchers listening a keys with values. For example:

private final Map<String, List<WatcherHolder>> register = new HashMap<>();

[wu-sheng]

That seems unrealistic, why do that?

[xzyJavaX]

We have such a demand here. And this is currently the design in skywalking. For example:

private void put(String key, WatcherHolder holder) {
    List<WatcherHolder> watcherHolderList = register.get(key);
    if (CollectionUtil.isEmpty(watcherHolderList)) {
        ArrayList<WatcherHolder> newWatchHolderList = new ArrayList<>();
        newWatchHolderList.add(holder);
        register.put(key, newWatchHolderList);
    } else {
        watcherHolderList.add(holder);
        register.put(key, watcherHolderList);
    }
}

It seems that skywalking has already considered this situation, so it is stored in a list

[wu-sheng]

I would say, the codes didn't consider a list although there is a list involved.
It is OK you support that, but I am wondering what is the real use case? Which two watchers could work for one key?

[lujiajing1126]

I would say, the codes didn't consider a list although there is a list involved. It is OK you support that, but I am wondering what is the real use case? Which two watchers could work for one key?

In our case, we want to share a single key acrosss plugins. For example,

• plugin.servlet_container.trace_http_parameters for tomcat, jetty, etc.
• plugin.redis.trace_parameters for jedis, lettuce, redisson, etc.
• ...

In such cases, users don't need to care about what underlying libraries are actually used.

[wu-sheng]

OK, go ahead.