zjncs opened a new issue, #5605:
URL: https://github.com/apache/rocketmq-dashboard/issues/5605
## Description
The parameterized, paginated data-source query carries the same
`@Cacheable(DATA_SOURCE_CACHE)` as the full-list method
(`SettingsService.java:223`):
```java
@Cacheable(DATA_SOURCE_CACHE)
public PageResult<DataSourceVO> listDataSources(String search, String type,
int page, int pageSize) {
```
But the comment documenting the cache (lines 213-216) scopes it to **the
full list only** ("The full-list endpoint is hit by every metrics tab on first
paint ... Caching it with the write paths evicted below keeps the user-visible
list correct") — the annotation on the parameterized overload contradicts the
documented intent and looks like a copy-paste of the annotation rather than a
decision.
The consequences:
- Spring's cache key is `SimpleKey(search, type, page, pageSize)` —
`search`/`type` are **arbitrary caller strings** on `GET
/api/settings/datasources/page`, which is not in
`AuthInterceptor.isAdminOnlyGetPath`, so any authenticated reader (not just
admins) can drive it
- The backing `ConcurrentMapCacheManager` (`CacheConfig.java:49-53`) has
**no TTL, no size bound, no eviction** — entries are only cleared by the
`allEntries` eviction on data-source create/update/delete
- Each distinct search term permanently pins a `PageResult<DataSourceVO>` —
DTOs that carry data-source auth fields (authType/username/password/bearerToken)
Failing test on master (2 of 2: the control proves the harness applies the
production caching — the full list is served once and cached; the parameterized
test asserts the documented contract):
```
[ERROR]
SettingsServiceDataSourceCacheBoundTest.parameterizedDataSourceSearchMustNotAccumulatePermanentCacheEntries
Expecting empty but was: {SimpleKey [search-1, null, 1,
20]=PageResult@…, ... 50 entries after 50 distinct searches
```
## Impact
Slow unbounded heap growth — every keystroke in the settings search box
creates one permanent entry — with credential-bearing DTOs retained in the heap
indefinitely; growth is bounded only by request rate.
## Expected behavior
The paged, user-parameterized query should not be cached (the documented
scope is the full list). If it ever needs caching, it would require a
TTL/bounded cache manager — but the documented intent supports plain removal.
## Environment
- branch: master (0228dad5)
- files: `SettingsService.java` (annotation at ~223), `CacheConfig.java`
(enabler)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
