Skip to content

[ISSUE #9308]For the orchestration of configuration filters, there are the following areas that can be optimized #9309 - #15034

Open
CLFutureX wants to merge 15 commits into
alibaba:developfrom
CLFutureX:RapperCL_fix_9308_new
Open

[ISSUE #9308]For the orchestration of configuration filters, there are the following areas that can be optimized #9309#15034
CLFutureX wants to merge 15 commits into
alibaba:developfrom
CLFutureX:RapperCL_fix_9308_new

Conversation

@CLFutureX

Copy link
Copy Markdown
Contributor

This PR replaces the previous one. See below for detailed changes. old pr

@github-actions

github-actions Bot commented May 6, 2026

Copy link
Copy Markdown

Thanks for your this PR. 🙏
Please check again for your PR changes whether contains any usage/api/configuration change such as Add new API , Add new configuration, Change default value of configuration.
If so, please add or update documents(markdown type) in docs/next/ for repository nacos-group/nacos-group.github.io


感谢您提交的PR。 🙏
请再次查看您的PR内容,确认是否包含任何使用方式/API/配置参数的变更,如:新增API新增配置参数修改默认配置等操作。
如果是,请确保在提交之前,在仓库nacos-group/nacos-group.github.io中的docs/next/目录下添加或更新文档(markdown格式)。


IConfigContext configContext = configRequest.getConfigContext();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't change the indent

@CLFutureX
CLFutureX requested a review from KomachiSion May 7, 2026 07:21
KomachiSion
KomachiSion previously approved these changes May 7, 2026
@KomachiSion

Copy link
Copy Markdown
Collaborator

@CLFutureX So sorry, nacos currently is doing spotless auto reformat code works so that your pr is conflict with this work.

Please solve conflict and use mvn spotless:apply after you solve conflicts

@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@KomachiSion

Copy link
Copy Markdown
Collaborator

@CLFutureX Sorry, there is one file is in conflicts. Please help to resolve it.

@nacos-community

Copy link
Copy Markdown
Collaborator

⚠️ Merge conflict detected

This PR has conflicts with the develop branch and cannot be merged in its current state. Please rebase or merge develop into your branch and resolve the conflicts:

git fetch origin
git checkout RapperCL_fix_9308_new
git rebase origin/develop
# resolve conflicts, then:
git push --force-with-lease

This is a one-time reminder. Feel free to @mention me for a re-review after conflicts are resolved.


Automated notification by github-manager-bot

@nacos-community nacos-community left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR refactors the client config filter chain so doFilter() no longer allocates a new VirtualFilterChain per invocation, using a prebuilt immutable linked chain instead. The direction is good and execution order is preserved, but the shared filterChain field lacks a visibility guarantee for reader threads — please address the critical finding below.

Findings

  • [Critical] client/src/main/java/com/alibaba/nacos/client/config/filter/impl/ConfigFilterChainManager.java:41 — filterChain should be volatile to prevent stale/null reads from unsynchronized doFilter().
  • [Warning] ConfigFilterChainManager.java:55 — buildConfigFilterChain() should be private, not public.
  • [Info] ConfigFilterChainManager.java:49 — redundant final buildConfigFilterChain() call in the constructor.
  • [Info] ConfigFilterChainManager.java:92 — chain rebuilt on every addFilter(), making bulk init O(n²).
  • [Info] client/src/test/java/com/alibaba/nacos/client/config/filter/impl/ConfigFilterChainTest.java:30 — no coverage for the new structure or concurrency.

Suggestions

  • private volatile IConfigFilterChain filterChain; (or hold the chain in a final holder published safely) is the minimal fix.
  • Consider rebuilding the chain only once after the initial ServiceLoader batch, and making buildConfigFilterChain() private.

Automated review by github-manager-bot

private final Properties initProperty;


private IConfigFilterChain filterChain;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filterChain is a non-volatile field written in the constructor / synchronized addFilter() and read from unsynchronized doFilter(). Client config filters run on listener/worker threads, so readers may observe a stale or null chain. Change to private volatile IConfigFilterChain filterChain; to ensure safe publication on every rebuild.

/**
* Build ConfigFilterChain.
*/
public void buildConfigFilterChain() {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

buildConfigFilterChain() is declared public but is only an internal implementation detail used by this class. Reduce API surface by making it private to avoid exposing new public methods in the client module.

for (IConfigFilter configFilter : configFilters) {
addFilter(configFilter);
}
buildConfigFilterChain();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The constructor already triggers buildConfigFilterChain() inside each addFilter() call, so this final call is redundant. Consider building the chain only once after all initial filters are added.

this.filters.add(i, filter);
}
buildConfigFilterChain();
return this;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addFilter() rebuilds the entire chain from scratch on every insertion, making bulk initialization (e.g., ServiceLoader in the constructor) O(n²). For typical filter counts this is fine, but consider whether the chain should be rebuilt only once after batch additions.

@@ -28,6 +28,7 @@ void testConfigFilterChain() {
ConfigFilterChainManager configFilterChainManager = new ConfigFilterChainManager(null);
configFilterChainManager.addFilter(new DemoFilter1());
configFilterChainManager.addFilter(new DemoFilter2());

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test change is only a blank line. Existing coverage preserves ordering with two filters, but does not exercise the new linked-node structure or guard against the visibility issue. Consider adding a multi-thread doFilter test or a test that verifies the chain is not recreated per invocation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants