Pre-check
Search before asking
Apache Dubbo Component
Java SDK (apache/dubbo)
Dubbo Version
Dubbo 3.3.x, branch 3.3 (source code review)
Steps to reproduce this issue
- Open
dubbo-common/src/main/java/org/apache/dubbo/common/utils/ConfigUtils.java
- In
replaceProperty() method (line 142): StringBuffer is used for a local variable, StringBuilder would be more appropriate
- In
loadMigrationRule() method: InputStream opened via url.openStream() is never closed after readString() returns — this is a confirmed resource leak
- In
loadProperties() multi-file loop: uses nested try-finally with empty catch blocks instead of try-with-resources
What you expected to happen
- Local variables should use
StringBuilder instead of StringBuffer when thread-safety is not needed
- All
InputStream resources should be properly closed using try-with-resources to prevent file handle leaks
- Empty catch blocks should be eliminated
Anything else
The most critical issue is in loadMigrationRule() where an InputStream opened via url.openStream() is never closed. In long-running applications this can lead to file descriptor exhaustion ("Too many open files" error).
I will submit a PR to fix all these issues.
Do you have a (mini) reproduction demo?
Are you willing to submit a pull request to fix on your own?
Code of Conduct
Pre-check
Search before asking
Apache Dubbo Component
Java SDK (apache/dubbo)
Dubbo Version
Dubbo 3.3.x, branch 3.3 (source code review)
Steps to reproduce this issue
dubbo-common/src/main/java/org/apache/dubbo/common/utils/ConfigUtils.javareplaceProperty()method (line 142):StringBufferis used for a local variable,StringBuilderwould be more appropriateloadMigrationRule()method:InputStreamopened viaurl.openStream()is never closed afterreadString()returns — this is a confirmed resource leakloadProperties()multi-file loop: uses nested try-finally with empty catch blocks instead of try-with-resourcesWhat you expected to happen
StringBuilderinstead ofStringBufferwhen thread-safety is not neededInputStreamresources should be properly closed using try-with-resources to prevent file handle leaksAnything else
The most critical issue is in
loadMigrationRule()where an InputStream opened viaurl.openStream()is never closed. In long-running applications this can lead to file descriptor exhaustion ("Too many open files" error).I will submit a PR to fix all these issues.
Do you have a (mini) reproduction demo?
Are you willing to submit a pull request to fix on your own?
Code of Conduct